Proposal for Configuration Redesign
Currently, configuration of Seam components (which includes configuration of Seam itself, via the built-in components, and configuration of user components) works via merging together properties found in the seam.properties file and the web.xml file.
I did it this way because it was the simplest possible thing that could work at the time. However, I'm now revisiting this decision. I've remembered that of course Java EE already provides a configuration mechanism for session beans (namely, environment entries defined in the deployment descriptor, together with the @Resource annotation), so configuration of a component looks like this:
@Stateless
@Name("myLogger")
public class MyLoggerBean implements MyLogger {
@Resource String logFilename;
...
}
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>MyLoggerBean</ejb-name>
<env-entry>
<env-entry-name>logFilename</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>mylog.txt</env-entry-value>
</env-entry>
</session>
</enterprise-beans>
</ejb-jar>The extra-nice thing about this approach is that env-entries are available via either injection, or via dynamic lookup from JNDI.
Obviously, I lean toward using the spec-defined mechanisms as much as possible. I've got a problem here, however, since plain JavaBeans components, especially the built-in seam components, are not Java EE 5 components, and so they don't have a component environment.
What I'm thinking to do is replace seam.properties with a seam.xml file patterned after the Java EE 5 approach, which looks something like this:
@Name("myLogger")
public class MyLoggerBean {
@Resource String logFilename;
...
}
<seam-archive>
<java-beans>
<bean>
<name>MyLoggerBean</name>
<env-entry>
<env-entry-name>logFilename</env-entry-name>
<env-entry-value>mylog.txt</env-entry-value>
</env-entry>
</bean>
</java-beans>
</seam-archive>My initial thought was to create some kind of java:comp namespace in JNDI even for JavaBeans components, but this is probably going to be a lot more trouble than it is worth, given that we have to wrestle with things like TomCat's read-only JNDI tree (ick). So, I'll probably just keep the config information internally in a built-in component.
What do you guys think of this proposal?
