Bundled distribution documentation
by Shane Bryzak
Module leads,
Can you please review the list below and confirm that the documentation
chapters are correct for your module. Also, I would like everyone to
take a moment to review the module documentation guidelines, as there
were a number of breakages in the bundled documentation build because
the guidelines weren't adhered to, particularly in the new modules for
Seam 3.1:
1) Always prefix the filenames of your documentation chapters with the
name of your module. E.g. security-authentication.xml,
security-authorization.xml, etc.
2) Whenever you assign an ID to a docbook element, such as a <chapter>
or <section>, ALWAYS prefix the id with your module name. For example,
<chapter id="security-introduction"> or <section
id="security-getting-started">. As all of the chapters for all modules
are combined when building the bundled documentation, all IDs must be
unique. This is a particularly time consuming problem to fix because
the error output from the Maven docbook plugin doesn't tell you which
files are the problem ones.
3) When adding, renaming or deleting a chapter of your documentation,
please notify me of the changes so that I can update
bundled_master.xml. This file must be manually kept up to date whenever
any documentation changes are made.
Thanks,
Shane
<?xml version='1.0' encoding="utf-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]>
<book lang="en" xmlns:xi="http://www.w3.org/2001/XInclude">
<toc />
<title>Seam 3</title>
<subtitle>Bundled Reference Guide</subtitle>
<xi:include href="bundled_credits.xml"/>
<xi:include href="bundled_intro.xml"/>
<part>
<title>Forge</title>
<xi:include href="forge-preface.xml" />
<xi:include href="forge-installation.xml" />
<xi:include href="forge-creating-basic-webapp.xml" />
<xi:include href="forge-plugin-dev.xml" />
</part>
<part>
<title>Seam Solder</title>
<xi:include href="solder-preface.xml"/>
<xi:include href="solder-gettingstarted.xml"/>
<xi:include href="solder-programmingmodel.xml"/>
<xi:include href="solder-annotationliterals.xml"/>
<xi:include href="solder-elextensions.xml"/>
<xi:include href="solder-resourceloading.xml"/>
<xi:include href="solder-logging.xml"/>
<xi:include href="solder-typeutilities.xml"/>
<xi:include href="solder-beanmanagerprovider.xml"/>
<xi:include href="solder-beanutilities.xml"/>
<xi:include href="solder-properties.xml"/>
<xi:include href="solder-unwraps.xml"/>
<xi:include href="solder-defaultbeans.xml"/>
<xi:include href="solder-genericbeans.xml"/>
<xi:include href="solder-servicehandler.xml"/>
</part>
<part>
<title>Seam Configuration</title>
<xi:include href="config-introduction.xml"/>
<xi:include href="config-xml-provider.xml"/>
</part>
<part>
<title>Seam Persistence</title>
<xi:include href="persistence-general.xml"/>
</part>
<part>
<title>Seam Transaction</title>
<xi:include href="transaction-general.xml"/>
</part>
<part>
<title>Seam Servlet</title>
<xi:include href="servlet-introduction.xml"/>
<xi:include href="servlet-installation.xml"/>
<xi:include href="servlet-events.xml"/>
<xi:include href="servlet-injectable_refs.xml"/>
<xi:include href="servlet-exception_handling.xml" />
<xi:include href="servlet-beanmanager.xml"/>
</part>
<part>
<title>Seam Security</title>
<xi:include href="security-introduction.xml"/>
<xi:include href="security-authentication.xml"/>
<xi:include href="security-identitymanagement.xml"/>
<xi:include href="security-authentication-external.xml"/>
<xi:include href="security-authorization.xml"/>
</part>
<part>
<title>Seam International</title>
<xi:include href="international-preface.xml" />
<xi:include href="international-installation.xml" />
<xi:include href="international-locales.xml" />
<xi:include href="international-timezones.xml" />
<xi:include href="international-messages.xml" />
</part>
<part>
<title>Seam Faces</title>
<xi:include href="faces-preface.xml" />
<xi:include href="faces-installation.xml" />
<xi:include href="faces-events.xml" />
<xi:include href="faces-scopes.xml" />
<xi:include href="faces-messages.xml" />
<xi:include href="faces-artifacts.xml" />
<xi:include href="faces-components.xml" />
</part>
<part>
<title>Seam Catch</title>
<xi:include href="catch-introduction.xml"/>
<xi:include href="catch-installation.xml"/>
<xi:include href="catch-client_usage.xml"/>
<xi:include href="catch-advanced_usage.xml"/>
<xi:include href="catch-integration.xml"/>
<xi:include href="catch-glossary.xml"/>
</part>
<part>
<title>Seam Reports</title>
<xi:include href="reports-preface.xml" />
<xi:include href="reports-installation.xml" />
<xi:include href="reports-usage.xml" />
</part>
<part>
<title>Seam Remoting</title>
<xi:include href="remoting-general.xml"/>
<xi:include href="remoting-model.xml"/>
<xi:include href="remoting-validation.xml"/>
</part>
<part>
<title>Seam REST</title>
<xi:include href="rest-preface.xml" />
<xi:include href="rest-installation.xml" />
<xi:include href="rest-exception-mapping.xml" />
<xi:include href="rest-validation.xml" />
<xi:include href="rest-templating.xml" />
<xi:include href="rest-client.xml" />
<xi:include href="rest-dependencies.xml" />
</part>
<part>
<title>Seam JCR</title>
<xi:include href="jcr-introduction.xml" />
<xi:include href="jcr-modeshape.xml"/>
<xi:include href="jcr-jackrabbit.xml"/>
<xi:include href="jcr-event-mapping.xml"/>
<xi:include href="jcr-ocm.xml"/>
</part>
<part>
<title>Seam JMS</title>
<xi:include href="jms-intro.xml" />
<xi:include href="jms-installation.xml" />
<xi:include href="jms-resource-injection.xml" />
<xi:include href="jms-messaging.xml" />
<xi:include href="jms-routing.xml" />
<xi:include href="jms-mapping-interfaces.xml" />
</part>
<part>
<title>Seam Validation</title>
<xi:include href="validation-introduction.xml"/>
<xi:include href="validation-installation.xml"/>
<xi:include href="validation-dependency-injection.xml"/>
<xi:include href="validation-method-validation.xml"/>
</part>
<part>
<title>Seam Wicket</title>
<xi:include href="wicket-preface.xml" />
<xi:include href="wicket-installation.xml" />
<xi:include href="wicket-features.xml" />
</part>
</book>
14 years
Solder MessageLogger and IllegalArgumentException
by Ove Ranheim
Hi,
The logging configuration with AS7 confuses me. Due a dependency of hibernate-search, I have upgraded to latest snapshot of it. And it works fine. I experienced that hibernate-search is unable to build the persistence-unit unless SLF4J is included, so I added an WEB-INF/jboss-deployment-structure.xml:
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.dom4j" />
<module name="org.apache.log4j"/>
<module name="org.slf4j"/>
<module name="org.apache.commons.logging"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
This solves all my former issues of logging dependencies and JBoss Logging works just fine and hibernate-search gets the logger instance it needs. I have experimented with including and excluding slf4j 1.5.10 and commons-logging 1.1.1, but it fails, unless I do the above.
Anyhow, Solder's TypeSafe Message log seems broken with AS7 and I get the following exception:
14:20:49,876 ERROR [stderr] (http-localhost-127.0.0.1-8080-4) java.lang.IllegalArgumentException: Invalid logger interface com.musific.log.MusificLog (implementation not found)
14:20:49,877 ERROR [stderr] (http-localhost-127.0.0.1-8080-4) at org.jboss.logging.Logger.getMessageLogger(Logger.java:2254)
14:20:49,877 ERROR [stderr] (http-localhost-127.0.0.1-8080-4) at org.jboss.logging.Logger.getMessageLogger(Logger.java:2215)
14:20:49,877 ERROR [stderr] (http-localhost-127.0.0.1-8080-4) at org.jboss.seam.solder.logging.TypedMessageLoggerProducer.produceTypedLogger(TypedMessageLoggerProducer.java:66)
Full log: http://pastebin.com/WQt11T47
When I deploy seam-booking example, it works perfect.
I suspect that hibernate-search (that is lucene) requires a conflicting version of slf4j, since that is a dependency causing PU not to be built unless it's there.
What's is the correct configuration for JBoss and Seam Solder logging in AS7?
What would be the right exclude (in jboss-deployment-structure.xml:) and logger jars to include.
Ove
14 years
RedirectHelper (Faces) or RedirectBuilder (Servlet)
by Cody Lerum
I have a particular use case where I need to:
1. End the current conversation if it exists
2. Redirect to a specific view-id
3. Optionally pass along some parameters.
This led me to create new RedirectHelper for Seam Faces that allows me
to do something like this.
redirectHelper.viewId("/admin/user.xhtml").param("oid",100).endConversation().redirect();
After doing so George Gastaldi and I found that this was partially
available in Seam Servlet through RedirectBuilder and can accomplish
the same like this.
redirectBuilder.redirect(request.get().getContextPath() +
"/admin/user.xhtml").param("oid", 100).send();
The only hang-ups being that it doesn't have support conversation
control (yet) and also assumes that if I have a "/" at the start of my
view-id that it is absolute and not to include the ContextPath. In
faces however I expect that the ContextPath will be added
("localhost:8080/myApp/admin/home.xhtml"). IMHO RedirectBuilder just
seems like it would be a little rougher to a new faces user too.
Does it make sense to alter the Seam Servlet RedirectBuilder to handle
these additional functions, or should I keep RedirectHelper in Faces
and have it be a softer way for users to work when redirecting within
JSF? I can utilize RedirectBuilder to handle the actual redirect in
the impl.
Thoughts?
14 years
Seam 3.1.0.Beta2 released
by Shane Bryzak
I'm happy to announce that the 3.1.0.Beta2 release is now complete, and
all modules have had their artifacts released to the JBoss Nexus
repository. We won't be providing individual module distributions,
however I will be building the bundled distribution over the next day
and uploading to Sourceforge & docs.jboss.org.
There is presently no concrete date for the CR1 release, we will now be
concentrating on testing Beta2, identifying blocker issues and
finalising the standard structure for module test suites, and general
quality checking / cleaning up of the modules. Once these items are
addressed then we'll announce the CR1 release date.
Thanks everyone for all the great work you've done for this release,
it's nice to see the level of polish in Seam increase, and see the
addition of a number of exciting new modules.
Shane
14 years
seam-wicket -> wicket-weld
by Clint Popetz
Hi,
I have a proposal from one of the wicket committers (Igor Vaynberg, who is
also one of my employees) to transition seam-wicket to become a wicket
module that integrates wicket with weld, so that it's supported by the
wicket team. This is a net win, in my opinion, because (a) the only code in
seam wicket is really just code to configure wicket's request cycle to
start/stop conversations and perform injection and has no other seam
dependencies, (b) this allows the release to be correctly synced to the
wicket releases, which we currently lag and are thus not compatible with,
and (c) he has more time to maintain this than I do, and would do a better
job of it.
Is this acceptable to the seam team? The only thing I really need is for
the weld 1.1.1 artifacts to be in the central m2 repo, because wicket is
published there and the central repo doesn't let you have dependencies on
non-central-repo artifacts. Is that reasonable/possible?
Thanks,
-Clint
--
Clint Popetz
http://42lines.net
Scalable Web Application Development
14 years, 1 month
Seam 3.1 beta release, take two
by Shane Bryzak
Guys and girls,
In the interest of moving things forward, I'm going to shortly start
working on the beta 2 release. There are still some issues that we're
working through with the multi-container testsuite configuration,
however with some help I've been able to resurrect the existing tests in
Solder to run in the latest version of Arquillian and I'm confident that
I can get the tests in the other modules passing successfully without
too much trouble. I would still like us to press on with the test suite
work, however I don't want it to hold up the release schedule.
Since the Beta1 release there have been a couple of important changes,
which I'll quickly summarise here:
1) seam-parent is now at the top of the food chain and no longer
inherits its configuration from weld-parent. This change is good for a
couple of reasons, first of all the disassociation from the Weld project
will help to reinforce that Seam is CDI implementation-independent.
Secondly it gives us total control over configuration for the Maven
plugins that we use, allowing us to update the plugin versions (which
I've already done, to the latest version of each plugin) and fine tune
the plugin configuration parameters for Seam.
2) I've decided against moving the logging feature out of Solder and
into its own module for now, as I discovered that it was too tightly
coupled to Solder to "de-tangle" it easily. I have however refactored
the logging API classes into their own package, org.jboss.seam.logging
which I think will be more intuitive for our users. I believe that the
Solder reference documentation still needs to be updated in response to
the changes made for SOLDER-102
(http://issues.jboss.org/browse/SOLDER-102) - Ken, could you please
confirm? If so, would you be willing to update the reference docs to
reflect the logging changes?
I am aiming for the Beta2 release this coming weekend, which means with
our 20+ modules now I need to get started pretty soon. If anyone has
any spare cycles and is able to help out with this, it would be greatly
appreciated. Each module needs to have its tests fixed, logging
refactored to use the new logging API package, and its distribution
thoroughly checked for correctness/completeness. If you'd like to
volunteer for a module or two, please catch me on IRC and we can work it
out there.
Thanks,
Shane
14 years, 1 month
