since we need to create a GWT view layer for examples from modules that
will go to Web Framework Kit product (those which use JSF 2 now), what
would you say about making these changes directly in community Seam 3
examples. As you can see at https://github.com/seam/ticket-monster
example, there would be submodules both for jsf-ui and gwt-ui, the java
classes would go into "core" submodule.
The original idea was to recreate those example and commit them into a
different (svn) repository. This approach would be real pain if
something changed in the original examples and we would need to do the
changes manually in the second repository. Furthermore, adding GWT view
layer into community Seam would engage the errai-cdi (Seam GWT) more. In
that case I would start with a config/rescue-princess example.
Seam QA Associate
As you may have noticed, we released Seam 3.0.0.Beta2 over the weekend.
This was an important milestone and I'd like to thank everyone for their
hard work in making it happen. The next big release is 3.0.0.CR1, due
at the end of this month. This release will be substantially more
important as it should closely resemble the final product that we plan
to release next month. By now, all APIs should be frozen, and we should
all be working on polishing up our modules, making sure the
documentation and examples are complete, and any major issues in JIRA
To ensure that we don't have a last minute rush to finish the bundled CR
release, I'd like to have all modules reach CR1 by Wednesday next week
(the 23rd of February) or even earlier if possible. If you feel your
module is complete enough for a CR release, please let me know and I'll
perform the release to Maven/Sourceforge for you - remember, earlier is
better! If you have outstanding issues that can be bumped to the 3.0.1
release, then please do so (I'll try to go through all the projects in
JIRA and set up future versions).
With Seam 3.0.0 on the horizon, it's time to get serious about putting
together the Seam 2 to Seam 3 migration guide. The purpose of this thread is
to capture requirements for this guide.
For a migration guide to be useful, it must be rooted in practical
procedures rather than theoretical correlations. Therefore, before drafting
a single paragraph, it’s important to capture the requirements for migration
from the user community. We'll then seek to answer those questions in the
guide. Once we have addressed those questions, we can fill-in the guide with
more generalized mappings for completeness.
So I ask, "what's your vision of an ideal migration guide?"
We don't have to answer the questions in this guide, though if you feel
compelled to answer a question, feel free to do so. Let's just try to stay
focused on identifying your concerns and questions, then we can discuss the
answers while reviewing the guide drafts.
Fire the requirements away. If you've already written requirements somewhere
on the web, you can just link to them.
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
I'm William from the GraniteDS project team. For those of you who have never
heard of it (most of you I guess ;)), GraniteDS is a Flex/Java EE
We've been working for some time now on the Flex/CDI integration and we
currently have a pretty decent implementation that allows to remotely call
CDI beans from Flex and integrate the Flex client event system with CDI
events. Think about Seam Remoting/Errai for Flex with end-to-end type-safety
between client and server.
As a next step we've been working for a few weeks on a deeper integration
with some of the Seam modules, mostly Seam Security and Seam International
for now. We proposed to Pete some time ago to contribute a Seam Flex module,
I wonder how it could fit now in the Seam 3 project and how we could proceed
Let me introduce a new Seam QE engineer, Marek Schmidt. Or better, let him
Hi, I am Marek Schmidt. My alma mater is Faculty of Information
Technology, Brno University of Technology, where I have spent last three
years as a grad student in the Natural Language Processing research
group. My interest in JBoss and Seam comes mainly from my involvement in
the KiWi research project (http://kiwi-community.eu), working on an
"Open Source social semantic platform" based on Seam2. My other
interests are related to my then-research, which was about Information
Extraction and Semantic Web.
When I'm not sitting in front of a computer, I'm most likely to be found
listening to some music from 1960s-70's, trying to play them on my
guitar or reading some good fiction.
Thank you Marek and good luck in Red Hat!
For an overview of the original proposal, please review
Why are we doing this?
The issue raised recently on the list is that during AfterBeanDiscovery, there is no guarantee that beans are available. This conflicts with the Egress side of the feature where the full observer method must be created during ABD. As a result, we cannot guarantee that looking up beans will work (in fact, we can typically guarantee it won't work). Therefor, we can not support generic qualifiers on the destinations that are involved in the mapping, the extension needs to be able to resolve the destination manually.
As a result, I am proposing a shorter, more defined API that will define the same type of interface level observer definitions, but have certain annotation requirements. There will continue to be no class level requirements for interfaces. Any class level annotations will be ignored.
public void methodName(@Observes @SomeQualifier MyObject obj, @JmsDestination(jndiName="jms/SomeQueue") Queue q);
This defines that an event fired of type MyObject qualified SomeQualifier will be sent to the queue at jms/SomeQueue. Then, messages received of jms/SomeQueue that can be cast to MyObject get fired under the same qualifier. You can have any number of arguments that are extensions of Destination (Queue & Topic). In addition, argument order is not taken into account. You can define your destinations in any order. JmsDestination is a Seam JMS provided annotation.
The second supported style uses @Resource. Note that there is a current issue with JBoss Meta that requires a limitation of the interface. https://issues.jboss.org/browse/JBMETA-328 .
public MyObject methodName();
Arguments to the method are optional, and are ignored. The functional behavior of this mapping is the exact same as the prior. In addition, JmsDestination can replace Resource in this case.
In both of these examples, you can add in @RouteType(Routing.INGRESS) or @RouteType(Routing.EGRESS). If either of these are present, then only the listed routing type will be created (ingress for in bound messages on queues/topics, egress for outbound events to queues/topics).
I hope that this is clear enough for all, but it's what I believe we can accomplish near term and still provide a concrete API to develop against that will work consistently across platforms.
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
To initialize connection to an OAuth service I need settings (service provider, Api Key, Api Secret, Callback url)
These settings are in a bean OAuthSettings with the given fields. I'd like to provide 3 scenario for user to provides those settings
1) have an @OAuthSet qualifiers with members that could let me write something like :
@Inject @OAuthSet(apiKey, apisecret, callback)
Knowing that the members of OAuthSet wouldn't be used directly for TwitterHandler creation but for the OAuthSettings bean injected in TwitterHandler
2) use seam config to initialize the values of OAuthSettings in beans.xml
3) Provide a way to have those settings as an entity bean loaded thru jpa by the consuming application
The strategy 1 seems nice but a bit tricky : I feel that I'll need a little more that a producer for that, perhaps an extension but I'm not quite sure.
I"m using strategy 2 right now but feel that my OAuthSettings bean implementation will not be compatible with an implementation for strategy 1
And concerning strategy 3, it makes me think that I'll have to provide an easy way for users to implement their own OAuth Settings initialization.
Any clue or advide on these matter ?
Twitter ; http://twitter.com/antoine_sd
LinkedIn : http://fr.linkedin.com/in/antoinesabotdurand
06 08 55 34 26