I am getting SEVERE: Class [ Lorg/jboss/logging/Logger; ] not found. Error
while loading [ class
org.jboss.seam.international.timezone.DefaultTimeZoneProducer ] when trying
to include Seam Faces into my poms...
so I've downloaded the sample (seam-faces-examples-short-ly) and tried to
run in... getting the same error.
I'm using NetBeans 6.9.1 and running the application from there (with
any ideas ?
Sebastian E. Ovide
I'm going to start the wheels rolling on the beta release, though first
I need to know if all modules are ready to go. If your module is in the
following list, can you please let me know if it's ready for inclusion
in the Seam beta:
If you're still waiting for a Solder release, then the good news is you
have a little more time as we won't be packaging the beta until the
current Glassfish issues with Solder are resolved. Either way, can you
please let me know the current status of your module.
I run into another GlassFish CDI visibility bug when working on Seam
REST beta release. Seems that jar to jar visibility does or does not
work based on the order in which jars are loaded.
You are fine as long as a jar with A bean is loaded before a jar with A
injection point. Otherwise, you'll get the UnsatisfiedResolutionException.
Seam QA Engineer
I am starting to prepare 2.2.1.Final release today.
2.2 branch is frozen until I create the tag
Thanks for respecting it.
Seam Product Lead
Red Hat Czech s.r.o.
612 45 Brno
Office phone: +420 532 294 287, ext. 82-62 087
mobile: +420 608 509 230
I was trying to write some more complex test scenario for wicket
module, but I have problem with CDI contexts. When I access second
page through SeamWicketTester object, request context still is the
same as in previous one. Is there any way to manualy flush context in
Without it it will be hard to write some integration test in realworld
business application when you need some more steps to test, and want
to see how different objects are injected to your pages.
As I understand there will be also impossible to test conversation
scope behaviour. Do you have any advice how to do it?
Or should I use frameworks like selenium?
It will be good feature to manually control context switching in
arquillian but I don't know whether it is possible.
I asked Rebecca Newton, one of the experts on our docs team if she could
put together a list of tips for us to follow when writing reference
documentation for the Seam modules. I think she's done an awesome job,
and produced an excellent guide which all of the module leads should
read carefully and try to incorporate into their documentation-writing
style. I've copied the guide below, which I hope everyone finds
useful. If you have any additional documentation-related questions
(including any related to documentation styling) please let me know and
I'll forward them on.
Tasks are good.
Be direct and concise. Tell the reader what they need to
know to do what they need to do, and no more.
This class is named after my great uncle who enjoyed Gulliver's Travels.
His favourite story was the Lilliputians, because he thought that little
people could do great things, despite how small they were. This is only
a small class, but it does great things. You can use it to change the
display of the widgets on the webpage.
Use the Lilliput class to change the widgets on the webpage. [/Lead in
to a procedure/]
The Liliput class is used to change the widgets on a webpage.
[/Incidental contextual information, where the Liliput class is related
to what follows, but is not the main focus/]
Readers approach documentation from a place of uncertainty and
confusion. They are looking for clarity and direction. Documentation
that presents multiple streams of thought and excessive amounts of
information quickly overloads the reader, and increases their sense of
confusion and uncertainty. Giving the reader the information necessary,
in clearly defined and digestible chunks, allows the reader to have a
"mastery experience". A mastery experience is where the reader goes from
a state of uncertainty to a state of increased certainty and knowledge.
This state change creates positive feedback, which increases a reader's
ability to digest more information. If the reader is overwhelmed with
too much information their ability to assimilate new information decreases.
The goal is to decrease the reader's uncertainty and increase their
sense of mastery of the material and their practical effectiveness.
Elaborate in the right place - use a "progressive reveal" to
avoid information overload.
You will need to turn on the computer. You will need to do this by
pressing the 'On' button. This will send power to the necessary circuits
and start the code that will make the computer run. It has lots of
different parts -- including memory, a hard disk, a modem, and more --
that work together. "General purpose" means that you can do many
different things with a PC. You can use it to type documents, send
e-mail, browse the Internet and play games.
Turn on the computer. For further information refer to <appendix one>.
Annotated examples are awesome.
Address the most common use case first. Deal with edge cases
*/Procedure: Booting the computer from the network/*
*1.*Turn on the computer.
*2.*Continuously press F12. On some computers, there is a different
button you can press. This button will probably be located on the front
of the keyboard device. On the T500 Thinkpad, you can use the
ThinkVantage button. This is located to the left of the keyboard.
*3.*A boot options menu will present. Choose the PXE boot option. You
can sometimes choose some of the options if you are confident in
*/Procedure: Booting the computer from the network/*
*1.*Turn on the computer.
*2.*Press the*F12*key when prompted.
*Result:*The boot options menu appears.
*3.*Choose the PXE boot option.
*Result:*The computer boots from the network.
<Appendix three> describes further boot options.
Screenshots are good from the end-user perspective, but if
to use them, you need to commit to keeping them up to date.
nothing more useless than an out-of-date screenshot.
The goal of documentation is to decrease uncertainty.
The sky is a reflection of light off the water. This creates a blue hue
that has been described as blue, baby blue, powder blue, and others, but
can look different depending upon the weather and other environmental
factors. It may also appear a different shade of blue depending upon a
person's individual perception of that colour. Blue is made up of
different colours, which are all part of the colour wheel.
The sky is blue because of reflection from water on the Earth's surface.
Reduce uncertainty. Avoid "should", "may", "must".
If you are caught in a storm, you may want to take shelter. You must not
shelter under a tree, or this could fall on you. You should take shelter
under a steady cover such as a house or awning.
Take shelter under a stable structure if caught in a storm. Avoid
low-lying areas prone to flooding.
Don't get caught up in how awesome your implementation is. The
customer is already convinced, since they are trying to use it.
Here is a paragraph from the Weld documentation:
The reason the same artifact can be deployed to both JBoss AS and
GlassFish, without any modifications, is because of all the features
being used are part of the standard platform. And what a capable
platform it has become!
This sentence loses nothing if the last sentence is removed, and you
will gain more credibility by being understated.
*Do not rant.*
On the other hand, don't be scared to use session beans just because
you've heard your friends say they're "heavyweight". It's nothing more
than superstition to think that something is "heavier" just because it's
hosted natively within the Java EE container, instead of by a
proprietary bean container or dependency injection framework that runs
as an additional layer of obfuscation. And as a general principle, you
should be skeptical of folks who use vaguely defined terminology like
This entire paragraph can be removed from the text without losing anything.
Introduce a new word in context, then explain what it means:
"You control widgets with sprockets. Sprockets are imaginary things made in
Use lists, tables, variablelists and other visual cues to
assist information assimilation.
Here as an example of a place where a list eases readability, from the
CXF User Guide.
CXF supports a variety of web service standards including SOAP, the WS-I
Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging,
WS-Security, WS-SecurityPolicy, WS-SecureConverstation, and WS-Trust
CXF supports a variety of web service standards including:
- The WS-I Basic Profile
- WS-Trust (partial).
Guided use case examples that increase in complexity are a
good way to progressively introduce features.
See the JBoss Microcontainer Guide for an example, available
Real world examples help the reader relate abstract concepts
to the their real-world problem space.
They don't have to be as involved as a full scenario as above, but small
case studies help more than, "Do this to configure your network." Here
is an example of a smaller real world scenario from the
Transactions_XTS_Administration_And_Development_Guide for EAP 6:
An Evening On the Town
The application [in question] allows a user to plan a social evening.
This application is responsible for reserving a table at a restaurant,
and reserving tickets to a show. Both activities are paid for using a
credit card. In this example, each service represents exposed Web
Services provided by different service providers. XTS is used to envelop
the interactions between the theater and restaurant services into a
single (potentially) long-running business transaction. The business
transaction must insure that seats are reserved both at the restaurant
and the theater. If one event fails the user has the ability to decline
both events, thus returning both services back to their original state.
If both events are successful, the user's credit card is charged and
both seats are booked. As you may expect, the interaction between the
services must be controlled in a reliable manner over a period of time.
In addition, management must span several third-party services that are
remotely deployed. Without the backing of a transaction, an undesirable
outcome may occur. For example, the user credit card may be charged,
even if one or both of the bookings fail. This example describes the
situations where XTS excels at supporting business processes across
multiple enterprises. This example is further refined throughout this
guide, and appears as a standard demonstrator (including source code)
with the XTS distribution.
Hopefully, most of the references are in your Javadoc, where developers
expect to find them.
References for command-line tools should really be in their --help option.
Hopefully, users don't have to look in documentation for reference
material at all.
If they do, make it useful and intuitive to navigate. Tables, lists, etc.
Here's the link to the incorporation of jboss-logging into solder:
Appreciate any comments/feedback as still new at this.
If it's easier for it to be a pull request just let me know.
There will undoubtedly be a few additions to this once I work out how i18n
module will look at the best location for some of these changes, solder or
On Tue, Jan 18, 2011 at 5:59 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> As a team we need to review Ken's improvements and provide feedback because
> it's a critical piece of Seam, not to mention it's importance to the i18n
> Ken, it would be best to post the branch where the changes live (sorry if
> I'm a step behind if you already have).
> - Dan Allen
> Sent from my Android-powered phone:
> An open platform for carriers, consumers and developers
> On Jan 18, 2011 3:30 PM, "Ken Finnigan" <ken(a)kenfinnigan.me> wrote:
> > On Mon, Jan 17, 2011 at 7:09 PM, Dan Allen <dan.j.allen(a)gmail.com>
> >> On Mon, Jan 17, 2011 at 18:49, Jason Porter <lightguard.jp(a)gmail.com
> >>> I need a Solder release (I'm working on switching to beans.xml), then
> >>> I can release the alpha, and a beta quickly for Catch, or we could
> >>> still keep it at alpha. Though because it's such an integrated piece
> >>> ideally it should be beta.
> >>> I think we should all be using the next release of solder if we can
> >>> make sure it works on Glassfish 3.0.1. I'll send a follow-up email
> >>> with my latest exception.
> >> +1
> >> Also, please use seam-parent 7 and seam-bom 3.0.0.b06...but stay tuned,
> >> may update to seam-parent 8 to pull in the Weld 1.1.0.Final.
> >> -Dan
> >> --
> >> Dan Allen
> >> Principal 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
> >> _______________________________________________
> >> seam-dev mailing list
> >> seam-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/seam-dev
> > +1 to Solder release, especially after some logging/i18n changes have
> > incorporated from some work I've done with Dan.
> > In terms of i18n, there are a couple of things I would like to get done
> > the first Beta, as it will likely change the API, that rely on the Solder
> > changes. Not sure whether I will be able to get them all complete by
> > Wed/Thu, though will see how I go tonight.
> > Ken
I'm pleased to announce that Brian Leathem  has stepped forward to take
the module lead role for the Seam Faces module . With Lincoln hard at
work on Forge and a vast portion of my time dedicated to interfacing with
the community, coordinating work across modules, and advocating for Seam,
Seam Faces became somewhat neglected. Brian is one of the community members
that brought this situation to our attention and we are glad that came
forward with a solution in hand.
While we shouldn't be shy to explore integrations with other UI
technologies, such as Wicket and Tapestry, JSF remains a critical part of
the strategy of Seam because of it's popularity, ubiquity and large
ecosystem. I'm hopeful that Brian will identify the areas where we can make
JSF more palatable, robust and developer-friends. There are a lot of ideas
to port from Seam 2 and new avenues to explore. Please help him by bringing
ideas forward and sending pull requests  that turn them into them a
I'd like to conclude by thanking all of the module leads for driving the
innovations in Seam, especially the leads from the community. We enjoy
working together (I hope), but most important we should be proud that we are
creating something useful that benefits each of us and the greater
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597