On 11/06/2010, at 11:20 PM, Pete Muir wrote:
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 />
What namespace is <cdi: bound to?
http://java.sun.com/xml/ns/javaee?
If so should I dump the seam namespace entirely, or just move the annotations into a
different namespace?
* 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.
https://jira.jboss.org/browse/SEAMXML-8
I added as many of the changes I could think of to the issue.
---------
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
I just had a look at this and as far as I can tell this is functionally pretty much
identical to @ManagedProducer. This will only work for methods however, as far as I know
it is not possible to portably get the actual instance of the bean, and you can't read
the field value from the proxy.
The other main difference is that @ManagedProducer requires you to specify the qualifiers
on the method, rather than inheriting them from the parent bean. Also @ManagedProducer
allows you to inject the InjectionPoint as a method parameter.
* Bean declaration at constructor level
This is pretty trivial to implement. A few comments / questions:
- Should the original bean be vetoed?
- Beans declared at the constructor level will not have interceptors or decorators, as
they will be added in AfterBeanDiscovery.addBean rather than
BeforeBeanDiscovery.addAnnotatedType.
- If you have producer methods / fields on the bean they will not be usable, as there will
be two identical producers so an attempt to inject the product will be ambiguous.
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
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev