jsf in seam 3
by Dan Allen
Working on the booking example has allowed me to gain a perspective about
what services we need right away out of the faces (jsf) module. Perhaps it
can be removed once the next rev of the EL is ready, but for now we need
JBoss EL to get parametrized EL expressions. That means providing a custom
JSF Application factory.
Fortunately, overriding the default Application impl got way simpler in JSF
2.0 since the spec now provides a base implementation class that you can
override a single method at a time. We can eliminate these overrides as they
come available in the platform. But for now we need it.
...that brings me to my next very important point. I think we need to be
developing against the JSF trunk. The last release, PR2, does not have any
of the features that we recently contributed, making development against PR2
almost pointless. I would like to compile a JSF release, call it 2.0.0-PR2_1
(or suggest another version number), deploy it to the JBoss repository, and
Seam can depend on that for now. If there are no objections, I will do that
today.
Going back to the faces module, instead of continuing with the
org.jboss.seam.jsf and org.jboss.seam.faces package split in Seam 3, I think
we should put all the faces classes under org.jboss.seam.faces and use
appropriate sub-package names. So in this case, I propose
org.jboss.seam.faces.application.SeamApplicationFactory and
org.jboss.seam.faces.application.SeamApplication for overriding the default
Application impl. We will also need the org.jboss.seam.el package (perhaps
module).
-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.
16 years, 9 months
Multiple WAR in EAR
by Stuart Douglas
I have done some investigating into multiple war support in seam. When
running a seam app with multiple wars you and up with two seam apps
running side by side, with different application contexts and
components. The Lifecycle and ServletLifecycle classes both maintain a
static reference to the servlet context (abstracted as a map in
LifeCycle). This means that only one of the seam apps will have their
application context stored in these classes. This seam app will work
fine. The seam app that is not referenced has the following problems:
- Cannot load resource bundles due to use of the wrong ServletContext in
ServletLifecycle (or wrong bundles loaded).
- Timers and async methods started in the second app will be run in the
app context of the first
- The wrong identity component will be created by the IdentityFilter.
- The resource servlet for the second app is run the app context of the
first, and will not work
- Wicket integration for the second app will not work
- Spring integration will not work in the second app
- jbpm integration in the second app is broken.
Some of these are easier to fix than others. The servlet and filter
problems are easy to fix as they have direct access to the
ServletContext and can simply pass it through to Lifecycle (abstracted
as a map of course)
The timer and async method issues are a bit harder. They will need to
store a reference to the application scope that they are meant to be run
in, same with the jbpm integration.
I do not know if it will be possible to get full spring support in multi
war apps, but I don't really know enough about spring to be able to say
one way or another.
As far as I can tell these are the only major problems with multi war
apps, if these are resolved it should work fine.
Stuart
16 years, 10 months
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.
16 years, 10 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
16 years, 10 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.
16 years, 10 months
[Fwd: Re: [jboss-dev] Classloader changes from AS 4.2.2 to AS 4.2.3 affecting launch of Tool built Seam apps]
by Max Rydahl Andersen
In case you are not on the jboss as dev list here is an explanation AND
workaround for the weird classloader and seam errors
we have had when we package with *standard* manifest.mf.
Basically JBoss will create multiple temp .jar's for one unique jar in
an deployment if they are not deployed in sequence.
Resulting in the applications seeing multiple URL's even though there
only are one.
/max
-------- Original Message --------
From: Jaikiran Pai <jpai(a)redhat.com>
Subject: Re: [jboss-dev] Classloader changes from AS 4.2.2 to AS 4.2.3
affecting launch of Tool built Seam apps
To: Max Rydahl Andersen <max.andersen(a)redhat.com>
CC: JBoss.org development list <jboss-development(a)lists.jboss.org>
Max Rydahl Andersen wrote:
>> 1) Should (EJB) *deployments* be listed in the MANIFEST.MF files of
>> other deployments. In this example the jboss-seam.jar which is a EJB
>> deployment (marked as a "module" in application.xml) is listed in
>> MANIFEST.MF of an xxx-ejb.jar deployment.
>
> We list these in manifest.mf since that is the only way Eclipse can
> know what is on the classpath; application.xml afaik does not
> attribute to the classpath - at least I never seen an IDE does that
> (they might be wrong ;)
> In any case, listing it in manifest.mf and in application.xml should
> not hurt anything since they should just resolve to the *same* jar.
I agree, adding it to the MANIFEST.MF should not be breaking the deployment.
>
>> 2) Is the duplicate temp files for the same jar file (jboss-seam.jar)
>> intentional? It's created once during the MANIFEST.MF parsing of
>> xxx-ejb.jar deployment and once during deploying jboss-seam.jar
>> deployment (which is listed as a module in application.xml).
> This is *the* bug I believe ? This will keep causing problems...
Someone who knows better about JBoss-4.x deployers would probably know
how to fix this.
>
> Any suggestion for a workaround that still allow me to use *standard*
> manifest.mf classpath entries ?
Luckily yes :) I looked at what the MainDeployer[1] does. The important
piece of code is :
private void parseManifestLibraries(DeploymentInfo sdi)
{
...//blah blah blah
if (classPath != null)
{
StringTokenizer st = new StringTokenizer(classPath);
log.debug("resolveLibraries: "+classPath);
while (st.hasMoreTokens())
{
...//blah blah blah
// Only deploy this if it is not already being deployed
if ( deploymentMap.containsKey(lib) == false )
{
/* Test that the only deployer for this is the
JARDeployer.
Any other type of deployment cannot be initiated through
a manifest reference.
*/
DeploymentInfo mfRef = new DeploymentInfo(lib, null,
getServer());
makeLocalCopy(mfRef);
URL[] localURL = {mfRef.localUrl};
mfRef.localCl = new java.net.URLClassLoader(localURL);
findDeployer(mfRef);
SubDeployer deployer = mfRef.deployer;
if(deployer != null&& (deployer instanceof
JARDeployer) == false)
{
// Its a non-jar deployment that must be deployed
seperately
log.warn("Found non-jar deployer for " + tk + ": "
+ deployer);
}
// add the library
sdi.addLibraryJar(lib);
}
}
So, if the classpath entry contains a reference to a jar which is
*already being deployed*, then it will *not* create a (duplicate) temp
copy while parsing the manifest entry. The (single) temp copy will be
created when the deployment jar (marked as module in application.xml) is
being processed for deployment.
So the *workaround* is to ensure that deployments which are referenced
in Classpath attribute of other deployments are deployed first. For ex:
in the application attached to the JIRA, the xxx-ejb.jar refers to
jboss-seam.jar (EJB deployment) in the MANIFEST.MF. So the trick is to
ensure that jboss-seam is picked up for deployment before xxx-ejb.jar is
picked for deployment (and the subsequent MANIFEST.MF processing). This
can be done by specifying the correct order of modules in the
application.xml and *also* specifying the module-order as "strict" in
jboss-app.xml (by default the module-order is "implicit" which follows
filename based deployment ordering [2]). So here's what i did:
application.xml:
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/application_5.xsd"
version="5">
<display-name>xxx-ear</display-name>
<!-- JBIDE-4166 Workaround - Make sure we deploy this first, since
this is referenced in xxx-ejb.jar-->
<module>
<ejb>jboss-seam.jar</ejb>
</module>
<module>
<ejb>xxx-ejb.jar</ejb>
</module>
<module>
<web>
<web-uri>xxx.war</web-uri>
<context-root>/xxx</context-root>
</web>
</module>
</application>
jboss-app.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-app
PUBLIC "-//JBoss//DTD J2EE Application 4.2//EN"
"http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd">
<jboss-app>
<!-- JBIDE-4166 : We need strict ordering to follow the order mentioned
in application.xml -->
<module-order>strict</module-order>
<loader-repository>
seam.jboss.org:loader=xxx-ear.ear
</loader-repository>
</jboss-app>
So all that JBoss Tools needs to do is add a intelligent ordering of the
modules in the application.xml and mark the application for strict
module ordering in the jboss-app.xml.
[1]
http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_4_2_3_GA/system/src/mai...
[2] This also explains why the deployment behaves differently when the
name of the deployment is changed.
>
>> --------------------
>> Archived deployment :
>> --------------------
>> When the application is deployed as an archive, the deployment
>> framework creates a exploded temp of the EAR in the tmp folder. It
>> however does *not* create temps for the sub-deployments or the
>> libraries within the ear. So there is only one jboss-seam.jar in
>> tmp/sometmpName.ear-contents. Because of this the logic explained
>> above, registers the SeamPhaseListener only once and hence no issues.
> Why the difference in behavior ? Legacy ? Intentional ?
Not sure. Someone who has more experience on the 4.x deployers might know.
>>> Why does it matter which letters we use in the deployment, i.e.
>>> fseam.ear behaves different that seam.ear ?
>> Though the JIRA mentions this, i don't see a reason why the name
>> should matter. I did not see any other explanation in the JIRA as to
>> how this fixed the issue. Is there some app which shows this behaviour?
> The problem is that it only shows up sometimes - I have seen it
> several times with capital letters (another bug) and even went so far
> to add a warning in the ui that using capital letters as the first
> character were not recommended.
> I'll try and see if I can find a way to reproduce the situation with
> different lett
When i read the JIRA, i thought the user was noting that changing the
name of the EAR fixed the issue. That's why i commented that naming of
the files should not matter (atleast for this specific issue). However
after what i explained above, related to implicit ordering of
deployments *within* an EAR, i think the user was talking about renaming
the deployments *within* the EAR. That makes sense now and it definitely
affects (= is expected) the deployment ordering.
-Jaikiran
16 years, 10 months
@Current DependentType or Manager.getInstanceByType
by Dan Allen
In the development of Seam 3, when we need a reference to another component,
which of the following should we be using (in general practice, not
necessarily exclusively)?
@Current Expressions expressions;
or
@Current Manager manager
...
manager.getInstanceByType(Expressions.class)
(bindings may exist too)
The heavy use of statics in Seam made it a huge pain to setup for
unit/multi-unit testing. It's a toss up for me w/ Seam 3 because while it is
easy to inject a mock Expressions in a pure unit test (no Web Beans
manager), it is arguably just as easy to inject a @Mock MockExpressions with
the thin @Artifact test framework. I still like the idea of being able to go
w/o the manager though.
As a follow up question, when we do an injection, should it be private,
package, or protected. Package seems to make the most sense now that it is
easy for us to put tests in the same package. Private seems like a bad
choice to me...with protected maybe a bit too exposed.
-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.
16 years, 10 months
Seam 2.1 branch
by Shane Bryzak
All,
Shortly (tomorrow evening my time) I'm going to branch Seam trunk into a
Seam_2_1 branch, and start working on the directory structure for Seam 3
in trunk. After discussing with Pete, we've decided that we are going
to go with a modular directory structure which will make it possible to
do separate releases for individual Seam modules (as well as other
advantages). The new directory structure will look somewhat like this:
/seam/trunk
/modules/trunk
/excel
/mail
/pdf
/remoting
/resteasy
/rss
/security
/sandbox/trunk
/other sandbox modules go
here,
/and once stable they
move to /modules
/examples/trunk
/existing seam examples
go here
/docs/trunk
/common/trunk
Could we please have all code checked in before this change - I'll
probably begin around the following time, and require a short code
freeze (hopefully just a few hours) while the restructuring is taking place.
http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&year=...
<http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&year=...>
Thanks,
Shane
16 years, 10 months
Seam 2.1.2
by Pete Muir
All,
Shane has requested we add CR2 in, to allow good testing of some
security changes he made. With this in mind, the final dates look like:
* Seam 2.1.2.CR2, code freeze Tuesday 28th April
* Seam 2.1.2, code freeze Friday 8th May
There are still a lot of open issues for 2.1.2.CR2, so please, pick up
a few and try to get the fixes in.
Thanks!
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete
16 years, 10 months
