Seam 3 space on JBoss Community
by Dan Allen
Two forces are converging that cause us to rethink where we are hosting Seam
3 project documentation and discussions. I'll enunciate those forces and
propose a solution that Lincoln and I have devised.
Seam 3 is a very different beast than Seam 2. In some ways, I liken it to
the relationship between Maven 2 and Maven 1. Both the Maven projects are
build tools that are founded on the same principle, a software project
management and comprehension tool that leverages an extensive ecosystem of
plugins that tie into a unified build lifecycle. But Maven 2 is built on a
different foundation than Maven 1, making them, in the end, very different
solutions.
Seam 3 relinquishes the context and dependency management and event
notification responsibility to CDI, something that evolved out of the Seam 2
core. Seam 3 is also focused on extensibility punctuated by container
portability. While you can expect similar convenient APIs and integrations
in Seam 3, and a bridge module that allows you to use or emulate Seam 2
components, pragmatically speaking, it's new project that is going to be
organized and governed very differently.
Having established that Seam 3 differs from Seam 2 is several fundamental
ways, mixing Seam 2 and Seam 3 information is massively confusing for
developers. I'm referring specifically to the forums and the wiki. The
driving force here is to establish a new "space" for Seam 3. Let's set that
point on the table and move to the next force.
Seam and Weld are projects brought to you by JBoss and its valued community.
Yet, for some time now, these projects have isolated themselves from the
JBoss community by being hosted outside (seamframework.org) of the JBoss
community umbrella (http://community.jboss.org). The creator of the
seamframework.org software is no longer with the team and the rest of us
must assume the responsibility of keeping it up to date. The problem is, any
work we spend on seamframework.org takes away from our ability to improve
Seam and Weld, review patches, analyze issues or write documentation. It's
an unnecessary drain. What makes it even more ridiculous is that we have a
entire team, the JBoss Community infrastructure team, that works full time
on providing a collaboration site to host projects, discussions and
documentation. A resource we are not currently leveraging.
Although it's a bigger discussion, we are reconsidering the use of the JBoss
Community for technical reasons. Lately we've identified some pain points
with seamframework.org that will immediately be solved by using Jive SBS
(the Java-based software behind community.jboss.org).
- Inability to monitor community discussion via "subscribe to this
thread"
- Inability to monitor comments on wiki pages
- Inability to post deep, complex links - including links to our own
threads on swfk.org
- A rigid navigation structure that cannot easily be altered
In short, we are concerned that we are lacking proper tools to effectively
manage and grow the Seam and Weld projects and community.
As simple as it sounds, there are still some considerations to take into
account before deciding to return Seam and Weld home to the JBoss Community.
That migration will require more planning. However, what Lincoln and I
suggest we can do as a first step is to take advantage of the need to create
a new space for Seam 3 and initiate that space in the JBoss Community. In
addition to the technical benefits, this would give us:
- a clean break for Seam 3, avoiding muddling with Seam 2 discussions and
information
- a proving ground to decide how we like the JBoss Community
collaboration platform, considering a full migration of
seamframework.orgin the future
- a chance for Seam community members across the board to establish their
JBoss Community accounts
- a better experience, in our mind
We propose:
- Creating a Seam 3 space at http://community.jboss.org with a user
discussion forum and wiki
- Creating a development subspace with a wiki (no discussion forum)
In the short term, we'll still use the seam-dev mailinglist for development
discussions (though we can consider enabling the discussion forums in the
development subspace if the e-mail bridge can be activated).
Would the majority of you be agreeable to this approach? It really will
provide a lot more clarity for Seam 3 and will show that we are sincere
about reuniting with the JBoss Community. Understand that this move will not
take away from the focus on portability in any way.
-Dan
p.s. Take a look at http://hibernate.org
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
13 years, 11 months
Seam POMs
by Pete Muir
All,
I've updated / rationalized these to use the defaults from weld-parent. Please let me know if this breaks your build somehow.
I'll be working on distribution stuff next.
Pete
14 years
Messages API in i18n
by Ken Finnigan
Hi Lincoln,
Sorry for taking so long to respond to your email!
I've taken a look at the Messages code you committed the other day and
I had a few questions about some areas that I didn't quite understand
in reading the code:
I noticed that Bundles contained @Named and was wondering what your
thoughts were about the bundles being directly EL accessible?
With BundleMessage I wasn't sure if it was purely the Builder pattern
that dictated that the BundleKey was set through a method call as
opposed to on the constructor or whether there was another reason?
What are the benefits to MessageFactory returning concrete
implementations as opposed to the MessageBuilder interface?
What are the benefits to Messages containing the same methods as
MessageFactory, without them saving the result in the Messages map?
Should Messages be @ConversationScoped to support parallel requests
from the UI?
If I've understood the code any message bundles that contain
properties need to be specified as strings in code. Was there any
thought of using XML Config to read them in, as this was something Dan
and I had discussed in the past?
If I understood the usage scenarios correctly they would include:
Messages.add(MessageFactory.info(new BundleKey("bundle", "key"),
2).build());
OR
Messages.add(MessageFactory.info(new BundleKey("bundle", "key"), 2));
OR
Creating an instance of MessageImpl directly and set the values before
passing it to Messages.add();
Could just be me, but these seem quite wordy just to add a message to
the UI?
What I am planning is to prototype what I have been thinking of doing,
using what you've already done as inspiration.
What are your thoughts on other features that should be in an Alpha 1
of i18n? I've got no problem with releasing Alpha 1 with the Messages
API you and Dan came up with to give me more time to think of possible
alternatives.
Ken
Sent from my iPhone
14 years
seamframework.org server host migration complete
by Dan Allen
Seam community,
On Friday, May 28th, we migrated the seamframework.org and
in.relation.toapplications and databases to a new server host (from
incubus.de in Germany to eApps.com in Atlanta, GA). There was an unexpected
24 hour period of downtime for seamframework.org because of a communication
breakdown in getting the DNS entries updated. The in.relation.to site had a
flawless transition in contrast.
The purpose of this migration was to bring the server under the ownership
and funding of Red Hat. This move is separate from the possible migration of
seamframework.org to jboss.org, which is still being discussed and
negotiated. Let's not reignite that topic in this thread.
Part of the complexity in this migration is that we were also consolidating
the ownership of all the domain names for seamframework.org and
in.relation.to (there are surprisingly a lot of them, and a lot of owners).
Some of the ownership transfer is still in progress, but the IP addresses
are now stable, so there should be no disruption throughout the rest of the
transfer process.
I'd like to thank Christian for making the transfer of the application very
easy. I'd also like to recognize the QE team (Jozef, Ondrej) for testing the
migrated site, Lincoln for helping with server configuration, Rodney for
provisioning the server, and both Pete and Rodney for staying on Red Hat IT
to get the DNS records updated.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
14 years
Nightly jobs
by Pete Muir
QA team,
These jobs need to run deploy whether or not the tests suite passes. All of them should specify maven.test.failure.ignore=true. Note that ci jobs that just run the tests need to specify this as well (so that build comes back as unstable, not failed when some tests fail).
I've updated a few jobs, but if you see this is missing, please add it!
Pete
14 years
Seam XML breaking tests with Arquillian
by Lincoln Baxter, III
See the included Test Case for an example: (Below)
The Latest SNAPSHOT of Seam XML and the Alpha2 of Arquillian (or SNAPSHOT),
exceptions occur when attempting to run any test suite. Any thoughts?
<dependency>
<groupId>org.jboss.seam.xml</groupId>
<artifactId>seam-xml-bean-config</artifactId>
<version>3.0.0-SNAPSHOT</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.arquillian</groupId>
<artifactId>arquillian-junit</artifactId>
<version>1.0.0.Alpha2</version>
<scope>test</scope>
</dependency>
... etc
Exception:
org.jboss.arquillian.impl.event.FiredEventException:
java.lang.RuntimeException: Could not get Deployment
at
org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:68)
at
org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115)
at
org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:78)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:151)
at
org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:170)
at
org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:272)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:166)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:118)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.RuntimeException: Could not get Deployment
at
org.jboss.arquillian.impl.DeploymentAnnotationArchiveGenerator.generateApplicationArchive(DeploymentAnnotationArchiveGenerator.java:78)
at
org.jboss.arquillian.impl.ClientDeploymentGenerator.generate(ClientDeploymentGenerator.java:57)
at
org.jboss.arquillian.impl.handler.ArchiveGenerator.callback(ArchiveGenerator.java:52)
at
org.jboss.arquillian.impl.handler.ArchiveGenerator.callback(ArchiveGenerator.java:42)
at
org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63)
... 14 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.impl.DeploymentAnnotationArchiveGenerator.generateApplicationArchive(DeploymentAnnotationArchiveGenerator.java:55)
... 18 more
Caused by: java.lang.IllegalArgumentException:
org/jboss/seam/international/test/timezone/override.xml not found in
classloader sun.misc.Launcher$AppClassLoader@77cde100
at org.jboss.shrinkwrap.impl.base.Validate.notNull(Validate.java:44)
at
org.jboss.shrinkwrap.impl.base.asset.ClassLoaderAsset.<init>(ClassLoaderAsset.java:64)
at
org.jboss.shrinkwrap.impl.base.asset.ClassLoaderAsset.<init>(ClassLoaderAsset.java:48)
at
org.jboss.shrinkwrap.impl.base.container.ContainerBase.addManifestResource(ContainerBase.java:464)
at
org.jboss.seam.international.test.timezone.DefaultTimeZoneOverrideTest.createTestArchive(DefaultTimeZoneOverrideTest.java:45)
... 23 more
org.jboss.arquillian.impl.event.FiredEventException:
java.lang.IllegalStateException: No org.jboss.shrinkwrap.api.Archive found
in context
at
org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:68)
at
org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115)
at
org.jboss.arquillian.impl.EventTestRunnerAdaptor.afterClass(EventTestRunnerAdaptor.java:86)
at
org.jboss.arquillian.junit.Arquillian$3$2.evaluate(Arquillian.java:174)
at
org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:272)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:166)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:118)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.IllegalStateException: No
org.jboss.shrinkwrap.api.Archive found in context
at org.jboss.arquillian.impl.Validate.stateNotNull(Validate.java:75)
at
org.jboss.arquillian.impl.handler.ContainerUndeployer.callback(ContainerUndeployer.java:58)
at
org.jboss.arquillian.impl.handler.ContainerUndeployer.callback(ContainerUndeployer.java:47)
at
org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63)
... 13 more
/*
* JBoss, Home of Professional Open Source
* Copyright 2010, Red Hat, Inc., and individual contributors
* by the @authors tag. See the copyright.txt in the distribution for a
* full listing of individual contributors.
*
* This is free software; you can redistribute it and/or modify it
* under the terms of the GNU Lesser General Public License as
* published by the Free Software Foundation; either version 2.1 of
* the License, or (at your option) any later version.
*
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this software; if not, write to the Free
* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
*/
package org.jboss.seam.international.test.timezone;
import javax.inject.Inject;
import org.jboss.arquillian.api.Deployment;
import org.jboss.arquillian.junit.Arquillian;
import org.jboss.seam.international.test.MockLogger;
import org.jboss.seam.international.timezone.DefaultTimeZoneProducer;
import org.jboss.shrinkwrap.api.ArchivePaths;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.spec.JavaArchive;
import org.jboss.shrinkwrap.impl.base.asset.ByteArrayAsset;
import org.joda.time.DateTimeZone;
import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;
@RunWith(Arquillian.class)
public class DefaultTimeZoneOverrideTest
{
@Deployment
public static JavaArchive createTestArchive()
{
return ShrinkWrap.create("test.jar",
JavaArchive.class).addClasses(MockLogger.class,
DefaultTimeZoneProducer.class).addManifestResource(new ByteArrayAsset(new
byte[0]),
ArchivePaths.create("beans.xml")).addManifestResource("org/jboss/seam/international/test/timezone/override.xml",
ArchivePaths.create("seam-beans.xml"));
}
@Inject
DateTimeZone timeZone;
@Test
public void testDefaultTimeZoneProducerDirect()
{
Assert.assertNotNull(timeZone);
Assert.assertEquals("America/Tijuana", timeZone.getID());
}
}
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
14 years
Re: [seam-dev] Let me know what you need for a first stab at the PDF/Mail port from Seam 2
by Lincoln Baxter, III
Well let's see if we can get you started, then :)
Have no fear!
Let me know if this helps:
- Create a JSF2 project. Here's a starting tutorial that takes about 5
minutes to get the project running.
http://www.javaserverfaces.org/get-started#TOC-Creating-a-JSF-2-and-CDI-p...
- Create a page that, when requested, calls a JSF Managed Bean action
(You can start by doing this with <f:event type="PreRenderViewEvent"
listener="#{myBean.mailListener}"> --
https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/facelets/inde...
- In that listener method, try to use something like this:
(HttpServletRequest)
request.getRequestDispatcher("/path/to/mail/view.xhtml").forward(MockHttpRequestObject,
MockHttpResponseObject);
- Try to capture the output of that new MockHttpResponseObject when JSF
has finished processing it .. the forward(...) method will actually start
another JSF request in the background.
This may or may not work, but it's what I would try first. If capturing the
output from a "background" request works, then getting the mail rendering
set up will be pretty easy. This, of course, requires that JSF be running,
but -- that's not such a bad requirement to start with. We can worry about
starting it up later.
--Lincoln
> On Fri, May 21, 2010 at 9:24 AM, Lincoln Baxter, III
> <lincolnbaxter(a)gmail.com> wrote:
> > I think for now these should be the same module. "Seam Docs" -- There's
> also
> > been speculation on whether a Mock Framework could be used to boot-up JSF
> > and render documents.
> >
> >
> http://community.jboss.org/wiki/MockObjectsforTestDrivenJSFDevelopmentorg...
> >
> > Another alternative is to build a UIViewRoot, and replace it during the
> > PreRenderViewEvent (which specifically states that it can be used to
> replace
> > the UIViewRoot.)
> >
> > Or.. there's the possibility of simply creating a "fake" Request and
> > Response object, and doing an internal forward in order to capture output
> > and capture the output (via the faked response object) to be used in
> > generating the PDF or Mail document.
> >
> > This last option is probably where I would start. I'd start by simply
> trying
> > to create a new request and capture the output -- just try on a normal
> page,
> > we can worry about generating pages that look like email documents after
> > this basic functionality is working.
> >
> > --Lincoln
> >
> >
> > 2010/5/21 Cody Lerum <cody.lerum(a)gmail.com>
> >>
> >> So a seam-mail and a seam-reporting?
> >>
> >> -C
> >>
> >> 2010/5/21 Tomaž Cerar <cerar(a)parsek.com>:
> >> > Hi guys,
> >> >
> >> >
> >> >
> >> > Will pdf and mail be separate modules?
> >> >
> >> >
> >> >
> >> > I would also like to contribute to both modules.
> >> >
> >> > I have done some extensive research of existing mail module code while
> >> > tracking down JBSEAM-3555 and have found out that current approach to
> >> > using
> >> > JSF in seam mail error-prone J
> >> >
> >> > Currently seam just uses jsf that was initalized in web application
> and
> >> > that
> >> > is why there are some ugly hacks to make it work when you invoke seam
> >> > mail
> >> > from from non-web request (ejb,mdb,...)
> >> >
> >> >
> >> >
> >> > Pete has sugessted that new seam-mail modul should start its own
> >> > instance of
> >> > JSF.
> >> >
> >> > Main problem with jsf is that there is no standard api to
> programaticly
> >> > set-up jsf enviroment. Idea is that seam implements RI (Mojarra 2.0)
> >> > with
> >> > implementation specific api and possible others if they provide any
> >> > machins
> >> > for starting up.
> >> >
> >> >
> >> >
> >> > I would also like to contribute do pdf module as we have some in-house
> >> > improvments and also some friends are willing to contibute huge
> upgrade
> >> > to
> >> > seam-pdf(forms,etc,..) but it is currently seam 2.0.x based.
> >> >
> >> >
> >> >
> >> > As I have not yet had much time to dive deeply into CDI and Seam 3(but
> I
> >> > folow development closly) a kick start as setting up seam3 module
> would
> >> > be
> >> > much apreciated. Altough I can help to »rip out« any seam 2 module...
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Cheers,
> >> >
> >> > Tomaž
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > From: seam-dev-bounces(a)lists.jboss.org
> >> > [mailto:seam-dev-bounces@lists.jboss.org] On Behalf Of Lincoln
> Baxter,
> >> > III
> >> > Sent: Thursday, May 20, 2010 4:57 PM
> >> > To: cody.lerum(a)gmail.com; Dan Allen; Seam Dev List
> >> > Subject: [seam-dev] Let me know what you need for a first stab at the
> >> > PDF/Mail port from Seam 2
> >> >
> >> >
> >> >
> >> > Hi Cody, you have my email address now.
> >> >
> >> > I'm actually not very familiar with Seam 2, which is one of the
> reasons
> >> > this
> >> > has been lower priority, but if you can "rip" that part out of Seam 2
> >> > and
> >> > make it a standalone maven project, I can help you get it set up as a
> >> > Seam 3
> >> > module and all that goodness :)
> >> >
> >> > seam-dev(a)lists.jboss.org (if you don't already know) is where we
> discuss
> >> > development, so you can also ask questions there --
> >> > https://lists.jboss.org/mailman/listinfo/seam-dev is where you can
> sign
> >> > up.
> >> >
> >> > Thanks for reaching out!
> >> > --
> >> > Lincoln Baxter, III
> >> > http://ocpsoft.com
> >> > http://scrumshark.com
> >> > "Keep it Simple"
> >> > !DSPAM:6,4bf54e13248112142088973!
> >
> >
> >
> > --
> > Lincoln Baxter, III
> > http://ocpsoft.com
> > http://scrumshark.com
> > "Keep it Simple"
> >
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
14 years
Weld Extensions Alpha2 available
by Pete Muir
All,
I have published the next release of Weld Extensions. It consists of a tidied up API, a long with a number of improvements:
* Determine if an interceptor is enabled
* Ability to load plug in new resource loaders (e.g. Servlet)
* Much tidier package structure
* rationalization of annotated type builders
Stuart has also made some improvements, which I'll let him outline.
I don't intend to push this release extensively, as the documentation is still (very) poor - but I wanted to get this out so that it can be used by modules depending on it. We'll get the javadoc fixed and alpha3 out soon.
Pete
14 years
