Automatic proxying of interfaces in weld extensions
by Stuart Douglas
After some discussions with Walter White I have added some experimental code to weld extensions to enable the automatic proxying of interfaces.
To demonstrate how this works, here is a sample:
@AutoProxy(QueryInvocationHandler.class)
public interface QueryService<T> {};
public interface UserQuery extends QueryService<User>
{
@Query("select u from user u where u.username=:1")
public User findUserByUsername(String username);
}
public class QueryInvocationHandler implements InvocationHandler
{
@Inject EntityManager entityManager;
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable
{
//run the query based on the annotations on the method
}
}
Any interface that extends QueryService will be automatically proxied by the container, using the InvocationHander specified in the @AutoProxy annotation. This proxy is registered as a bean, and if any qualifiers are present on the Interface being proxied these are added to the bean. It is also possible to inject into the InvocationHandler.
I also plan to make @AutoProxy a meta annotation, so the above could also be represented as:
@AutoProxy(QueryInvocationHandler.class)
public @interface QueryService{}
@QueryService
public interface UserQuery
{
@Query("select u from user u where u.username=:1")
public User findUserByUsername(String username);
}
Does all this sound ok, or does it not have a strong enough use case to include it in Weld Extensions?
Stuart
14 years
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
14 years
Development stages
by Ken Finnigan
I've been thinking that we need a way to distinguish between development
or production so that we can perform extra start up checking while in
development that we wouldn't want to perform in production. It's been
suggested that we could do something similar to what has been added to
myfaces
<https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/core/api/sr...>,
to make it easier to standardise in the future.
If everyone felt it was beneficial to have a "project stage", should it
be added as a Seam module or a Weld Extension?
Ken
14 years, 1 month
Module reviews
by Pete Muir
All,
A series of notes from the review Gavin and I did of the work so far on Seam 3 and what needs to be done.
Faces
--------
* Attaching a FormValidator would work better if we attached by form id. For example:
<h:form id="locationForm">
...
</h:form>
@FacesValidator("locationForm")
public class LocationValidator implements Validator {
...
}
would automatically cause this validator to be used.
* We need a pages.xml replacement still. Gavin posted to seam-dev about an enum-based navigation system called "Replacing pages.xml" on 29th Feb 2010. The concept here is pretty elegant and well proven (e.g. Wicket).
* Page fragment caching
* URL Rewriting
* conversationId tag
* object/entity converter
* review how many of the ancillary support tags (e.g. label) actually made it into JSF.
* support for Seam Managed Transactions
Lincoln - please can you make sure we have the relevant JIRAs to track these and post for trackback.
---------
Servlet
---------
All looks good.
---------
Seam XML
---------
* CDI annotations need to come from the CDI namespace, not the Seam namespace. For example:
<s:Qualifier /> or <s:Specializes /> -> <cdi:Qualifier /> or <cdi:Specializes />
* A few deviations from the original spec, we should double check each one.
Otherwise, looking great. Stuart, will you make sure we have a JIRA for both of these, and post for trackback.
---------
i8ln
---------
* Currently, all the examples show using XML to set up the locales and default system locale. Need some examples showing how to set this in Java (does this exist? probably use the same approach as for setting the client locale - events)
* Approach of treating messages like a logger is good
* Resource bundle handling is wrong, it produces far to strong coupling between specifying the key and specifying which method to log (bundle key specification is totally orthognal to actual logging call)
* In general, rewrite the messages API along the lines of JBoss Logging 3 - I will take the lead on this. This will then be totally consistent with our logging approach once we switch from slf4j to JBoss Logging 3.
Ken, can you make sure there are JIRAs and post for trackback
---------
WeldX
---------
* Support for @Introduces
* Bean declaration at constructor level
I will create JIRAs and post for trackback. Stuart, are you interested in working on some of this?
---------
Persistence
---------
* Currently languishing. I will take the lead.
* Make sure it contains @TransactionScoped
* Support for SMPC
* Support for persistence and TX outside Java EE
* Hibernate search support
----------
CRUD framework
----------
* Gavin will jot down some notes in a blog to get this started.
---------
Compatibility
---------
* Target is Seam 3.1
* Conversion tool may be useful, but we need a bridge
* If Seam 2 is present, may have to disable Seam 3 modules
---------
JMS
---------
* Change back to original design from spec draft from 20090520 where we use the producer field pattern to provide access JMS artifacts (I will follow up with a copy). This is much more flexible, as it allows the use of @Alternative etc.
* Routing of events - change back to original design from spec draft (as above) where we generate proxies for relevant interfaces with @Observes:
interface JMSMapping {
void myMapping(@Observes @SomeQualifier SomeType type, @MyTopic Topic topic);
}
and support the use of @Alternative on this to enable disable/disable it.
----------
Security
----------
* Review held back until more details emerge
Other modules we didn't discuss in any detail, but include: Remoting, jBPM, Drools, seam-gen
Pete
14 years, 1 month
Seam 2.2 : EjbSynchronizations is still in SESSION scope
by Denis Forveille
Marek,
You said in a previous message that you rollbacked the changed
you'vemade in EjbSynchronizations (Change the scope from EVENT to
SESSION) but the current version still has the scope set to SESSION
Could you commit EjbSynchronizations with the scope set back to EVENT
as before?
Thanks
14 years, 1 month
Request for new JIRA project SEAMJBPM
by Tihomir Surdilovic
Hi Shane, I would like to request addition of the SEAMJBPM jira project.
The jbpm module (shell) is available in SVN.
* the key of the project: SEAMJBPM
* the user friendly name of the project: seam-jbpm
* the jboss.org username of the project lead: tsurdilovic
* a description of the project: seam 3 integration with jbpm
Let me know if you need any more info.
Thanks.
14 years, 1 month
