Re: [seam-dev] Testing seam modules
by Dan Allen
Arquillian is the future of the integration testing (anything beyond a unit
test) for Seam 3, the CDI TCK and probably the JBoss community in general
(though that will take some proving).
Please give it a try and stop by the Arquillian forums if you have questions
or feedback. [1] We don't have a release out yet, so you need to compile
from source. We should be getting an alpha out the door pretty soon ;)
Jordan is one of the first Seam 3 module drivers to use Arquillian, so you
can use his JMS module as a reference.
[1] http://community.jboss.org/en/arquillian
- Dan Allen
Sent from my Android-powered phone:
An open platform for carriers, consumers
and developers.
On Feb 25, 2010 1:20 AM, "Jordan Ganoff" <jganoff(a)gmail.com> wrote:
To test the Seam 3 JMS module I've been using JBoss Arquillian:
http://community.jboss.org/en/arquillian. It's extremely easy to use and
has been working for in container testing on JBoss AS 6.0.0.M1 and now M2.
The guys heading up Arquillian have been working hard on it.
On Wed, Feb 24, 2010 at 6:08 PM, Stuart Douglas <stuart(a)baileyroberts.com.au>
wrote:
>
> Has there...
--
Jordan Ganoff
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
14 years, 1 month
Seam 2.2.1.CR1 and frozen branch 2.2
by Marek Novotny
Hi all,
all the issues are done for 2.2.1.CR1 so I am starting the
release process :-)
All, please don't make any commits to 2.2 branch until I sent you info
about tagged version and unfrozen branch.
--
Marek Novotny
--
Seam Product Lead
Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno
Email: mnovotny(a)redhat.com
Office phone: +420 532 294 287, ext. 82-62 087
mobile: +420 608 509 230
14 years, 1 month
Seam 2.2.1.CR1 Initial testing results
by Ondřej Skutka
Hi!
Please review these library changes since 2.2.0.GA:
Added libraries:
> ./lib/backport-util-concurrent.jar
> ./lib/blazeds-common.jar, 3.2.0.3978
> ./lib/blazeds-core.jar, 3.2.0.3978
> ./lib/blazeds-proxy.jar, 3.2.0.3978
> ./lib/blazeds-remoting.jar, 3.2.0.3978
> ./lib/httpclient.jar, 4.0
> ./lib/jcip-annotations.jar
> ./lib/jcl-over-slf4j.jar, 1.5.8
> ./lib/resteasy-jettison-provider.jar
> ./lib/jboss-seam-flex.jar
> ./lib/src/jboss-seam-flex-sources.jar
Removed libraries:
< ./examples/wiki/lib/jboss-archive-browsing.jar
< ./lib/FastInfoset.jar
< ./lib/sjsxp.jar
< ./src/test/ftest/lib/ant-launcher.jar
< ./src/test/ftest/lib/ant.jar
< ./src/test/ftest/lib/cargo-core-uberjar-1.0.jar
< ./src/test/ftest/lib/jboss-test-1.0.5.GA.jar
< ./src/test/ftest/lib/selenium-java-client-driver.jar
< ./src/test/ftest/lib/selenium-server-standalone.jar
< ./src/test/ftest/lib/testng-5.8-jdk15.jar
Library changes:
/lib/spring.jar 2.0.6 -> 2.5.5
/lib/gen/glassX.jar 3.3.1.GA -> 3.3.3.CR1
/lib/gen/darkX.jar 3.3.1.GA -> 3.3.3.CR1
/lib/gen/laguna.jar 3.3.1.GA -> 3.3.3.CR1
/lib/richfaces-api.jar 3.3.1.GA -> 3.3.3.CR1
/lib/richfaces-impl.jar 3.3.1.GA -> 3.3.3.CR1
/lib/richfaces-ui.jar 3.3.1.GA -> 3.3.3.CR1
/examples/wiki/lib/hibernate-annotations.jar 3.3.0.GA -> 3.4.0.GA
/examples/wiki/lib/hibernate-commons-annotations.jar 3.0.0.GA ->
3.1.0.GA
/examples/wiki/lib/hibernate-entitymanager.jar 3.3.1.GA -> 3.4.0.GA
/examples/wiki/lib/hibernate-search.jar 3.0.1.SNAPSHOT-20080202 ->
3.1.1.GA
/examples/wiki/lib/hibernate-validator.jar 3.0.0.GA -> 3.1.0.GA
/examples/wiki/lib/hibernate3.jar 3.2.3.ga -> ???
/lib/jboss-el.jar 1.0_02.CR2 -> 1.0_02.CR5
/lib/jettison.jar ??? -> 1.1
/lib/jta.jar 1.1 -> ???
Ondra
14 years, 2 months
Re: [seam-dev] XML configuration
by Dan Allen
There was a lot of interest in the XML configuration/definition of beans at
JSFDays. It will definitely be a crown jewel of the Seam 3 "portfolio" ;)
I'll do a more complete post w/ feedback in general, but I just wanted to
mention that.
- Dan Allen
Sent from my Android-powered phone:
An open platform for carriers, consumers
and developers.
On Feb 24, 2010 10:12 PM, "Stuart Douglas" <stuart(a)baileyroberts.com.au>
wrote:
There is some docs in the repo, to build them run
mvn jdocbook:generate
from the docs directory. It basically just a re-hash of the forum post at
http://www.seamframework.org/Community/XMLExtension
Stuart
________________________________________
From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] On
Behalf Of Pete Muir [pmuir(a)redhat.com]
Sent: Thursday, 25 February 2010 2:42 AM
To: Ken Finnigan
Cc: seam-dev(a)lists.jboss.org
Subject: Re: [seam-dev] XML configuration
Stuart Douglas has been working on XML config for Seam 3. If you search back
through the weld-dev a...
14 years, 2 months
Testing seam modules
by Stuart Douglas
Has there been any discussion on testing seam 3 modules? Currently I have been using weld-se to test the XML extension (which is currently broken due to changes in weld-se, this should be fixed today), however this is a stop gap solution and it needs to be moved to a proper in container setup before I can start working on wiring up EJB's etc using XML.
I think that the ideal solution would be a seam-test module, that can be used to test other modules and end user projects build with seam.
Stuart
14 years, 2 months
XML configuration
by Ken Finnigan
All,
I will begin work on the i18n module today but I had a question
regarding XML configuration that I could not find an answer to
elsewhere.
Is it envisaged that seam 3 will contain a components.XML file, or
possibly one per module, for config? If so, is it planned that the
XML module becomes the way for another module to read the content?
Thanks
Ken
Sent from my iPhone
14 years, 2 months
Seam 3 Internationalization & Localization module ideas / thoughts
by Ken Finnigan
All,
I'm currently in the process of pulling together some thoughts and ideas
as to what to include in the new i18n and l10n module within Seam 3.
Here are some initial ideas that have been put forward:
- Remove all hard dependencies to JSF from within the module
- i18nable logging
- Pushing the default locale to JSF and other view layers based on
the system locale
- Modify the message interpolation mechanism to remove the use of
#{} and be consistent with Java by using simply {}
- The ability for multiple view frameworks to co-exist with the
appropriate messages being returned to the calling framework. My
initial thoughts on this are to convert the existing StatusMessages
class into a conversational scoped bean which can be used by application
code to create a message for display. Then a view framework would
create the mechanism to convert the StatusMessages content into messages
appropriate to them. With JSF this could be achieved by taking the
existing FacesMessages class and injecting the StatusMessages instance
(while retaining the extends) to retrieve the messages that are present
and FacesMessages can be used by SeamPhaseListener as it is now.
Any comments on the above are most welcome, as well as any thoughts
about what else would be useful to have within this module.
Regards
Ken
14 years, 2 months
Replacing pages.xml
by Stuart Douglas
I have been thinking about the replacement for pages.xml. Even though JSF2 has made some aspects of pages.xml redundant, pages.xml is still important as it allows you to apply actions/security setting etc to a large number of pages at once using wildcards. With that said however it would be nice to move to a design that is more typesafe and extensible. I have come up with a preliminary idea of how this might work, I will explain with an example:
@PageMetadata
public @Interface SecurityConfig
{
boolean loginRequired();
String restrict();
}
/**
* This bean will only be considered for injection when the context path is
* /app/restricted/*, and it is the most specific page available.
*/
@ViewId("/app/restricted/*")
@SecurityConfig(loginRequired=true)
public class RestrictedArea extends Page
{
}
This may also be configured via XML using seam-xml.
There is nothing special about the page class, it is an empty class
that is provided solely to be configured with annotations:
<Page>
<ViewId>/app/restricted/*</ViewId>
<SecurityConfig loginRequired="true" />
</Page>
The application can get access to this information in a number of ways:
@Inject PageDataProvider<SecurityConfig> data;
public void doStuff()
{
//get the most specific result
SecurityConfig security = data.get();
//get all applicable results
List<SecurityConfig> secinfo = data.getAll();
//secinfo is ordered from most to least specific,
//secinfo.get(0) will be equal to data.get()
}
Alternatively the most specific result can be injected directly:
@Inject SecurityConfig data;
We could also support an event based approach:
public void pageEvent(@Observes @Rendered("/secure/*") Page page, SecurityConfig config)
{
//do stuff
}
Does this sound like a good approach? I am fairly sure all this can be implemented as a portable extension.
14 years, 2 months
