qualified bean names
by Dan Allen
On Fri, Apr 9, 2010 at 10:53 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> * Changed the requirement to be to use org.jboss.seam.* as the prefix for
> the bean name. We will add an extension for CDI that allows aliasing
> namespaces such as org.jboss.seam to a short prefix (such as seam.). Anyone
> fancy coding this up quickly for Weld Extensions?
>
I missed this one. We had a long chat about this in #seam-dev a few weeks
ago and drew these conclusions.
Using long qualified bean names (i.e.,
@Named("com.acme.framework.module.beanName")) immediately introduces the
need to shorten (or import) them in someway. The approach that was taken in
Seam 2 was to qualify every name with the prefix "org.jboss.seam." and then
add all of these namespaces to a list of auto-imports in jboss-seam.jar. But
that defeated the whole purpose of having a qualified name since now each
component had two names, the short one (e.g., "statusMessages" and the long
one "org.jboss.seam.international.statusMessages"). So global imports
provided by the library are meaningless.
That brings us to local imports. Since bean names are only meant to be used
in the EL (which in most cases is the view), we ask, how to we import the
names in the view? I posed this very question to Lincoln. I suggested:
<s:importNames namespace="org.jboss.seam.faces"/>
Understandably, he challenged me by saying (paraphrase) "you must be doing
something wrong if you need that".
We came to the understanding that having a protected namespace is good, but
having a namespace that you can't easily type is bad. We concluded that
since we "own" the Seam name, people should be willing to accept that we can
prefix our names with "seam" and that should be enough to ensure that they
don't conflict with application names. In the example above, I can avoid the
import by using the name:
seam.statusMessages
I think bean names should be unique across all our modules so we can avoid
having to put the module name in the bean name
"seam.international.statusMessages". You can always tweak the name to make
it unique.
The question we need to ask, is, why not?
-Dan
--
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, 8 months
Java 5
by Pete Muir
Just to remind everyone (not sure if this is a problem or not atm ;-) but all Seam modules should be developed using Java 5 unless there is a strong reason to use Java 6. We should used the Hudson jobs to ensure that the code builds with Java 5.
14 years, 8 months
Need for Common Annotation-attribute scanning/parsing utility (or CDI API/SPI)
by Lincoln Baxter, III
As many of you know, when creating API annotations for Seam Modules, we have
an interesting situation:
https://jira.jboss.org/jira/browse/WELDX-95
Due to the fact that annotations can include meta-annotations, we need to
recursively scan the annotation hierarchy in order to obtain the correct
annotation instance (or null if it isn't declared,) then return that
annotation in order to access the attributes.
This becomes even more complex when annotations are added via the
seam-xml-config module, but I'll let Dan or Pete explain that one.
It seems likely that we will need a new API/SPI in CDI in order to
appropriately address performance concerns with doing such recursive,
synchronized (locking!) lookups.
There are several questions to address:
1. Where do we allow nested/meta-annotations?
2. How do we address the performance concerns where they are allowed?
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
14 years, 8 months
Seam JIRA for Seam 3
by Pete Muir
All,
As we split Seam into modules (and as some like remoting and XML approach a beta release), we need to consider how JIRA should look for Seam 3.
We plan to release modules independently, with a "feature-boxed" lifecycle, releasing modules either as features are added, or critical issues arrive. We also plan a "bundle release" at regular intervals, which takes all the modules, and provides a single stack that are tested to work well together.
Keeping JIRA simple and monolithic has the advantage of being easy to understand and point people at. We can use components to track a module. We would have to prefix the version with the module name, and tracking issues to releases becomes pretty difficult.
Using a JIRA project for each module allows much cleaner tracking of issues to releases.
I favour the latter, but am interested in others opinions.
Pete
14 years, 8 months
Extending weld-extensions generic beans
by Stuart Douglas
After talking with Tihomir over the last few days about the seam-drools module I think that there is base functionality that is missing that belongs in weld-extensions as it is similar to the existing generic bean code.
I will use an example from the drools module to outline the problem:
The drools module has a DroolsConfiguration object that contains configuration, this can be installed via XML and there can be multiple DroolsConfigrations per app. for every DroolsConfiguration several object need to be produced e.g. KnowledgeBase, StatefullKnowledgeSession and a KnowledgeRuntimeLogger.
currently we would need to do something like this:
< d:DroolsConfiguration>
<app:SomeQualifier>
...configuration
</d:DroolsConfiguration>
<d:KnowlegdeBaseProducer>
<d:producerMethod>
<app:SomeQualifier>
<s:parameters>
<d:DroolsConfiguration>
<s:Inject/>
<app:SomeQualifier/>
</d:DroolsConfiguration>
</s:parameters>
</d:producerMethod>
</d:KnowlegdeBaseProducer >
...same for StatefullKnowledgeSession, StatelessKnowledgeSession, KnowledgeRuntimeLogger etc.
and wire up a producer like that for every object being created from the DroolsConfiguration. This is not good. The user should be able to just wire up the configuration and the rest of the beans should be created automatically. I think we should be able to do something like this:
@Generic(DroolsConfiguration.class)
class KnowledgeBaseProducer
{
@Produces
@GenericQualifiers
public KnowledgeBase producerMethod(@Inject @GenericQualifiers DroolsConfiguration config )
{
//do stuff
}
}
@Generic tell the extensions to register a new KnowledgeBaseProducer bean for every DroolsConfiguration found.
@GenericQualifiers is replaced with the qualifiers on the DroolsConfiguration object when the bean is added.
This means that all an end user has to do is wire up a single DroolsConfiguration object and everything just works.
Does this sound like a good idea? Is there anything I have overlooked?
Stuart
14 years, 8 months
Review of development guidelines
by Pete Muir
* Updated the license info to indicated LGPL 2.1 is used with APL being considered by leadership
* noted we will likely switch to jboss logging 3.0 when available
* Changed the annotation location to reflect the Java convention of
@Model
public class Foo {}
* changed the requirement to write javadoc for internal APIs (no such thing exists ;-) to write comments for impl detail
* changed the packaging requirements for interceptors and decorators and all public api classes as discussed previously
More to come...
14 years, 8 months
