Either one of these is fine with me, although I think the best thing to
do would be to simply change it to an attachment list. I don't think
there will actually be many double up services, and we can just remove
the double up's before we use the list.
Stuart
Eduardo Martins <mailto:emartins@redhat.com>
5 September 2012 1:34 AM
This naming processor, which sets up a DU attachment for a set of jndi
binding service dependencies (to be added later on the component start
service so JNDI bindings are up when the component needs), is
currently bound to INSTALL phase, and this is limiting the usage of
such set. For instance in
https://issues.jboss.org/browse/AS7-5443 the
naming processors who set up app and module context, which are bound
to POST_MODULE phase, need to setup java:app/AppName and
java:module/ModuleName, and these need to be also up when the
component needs (e.g. @PreDestroy).
I see two ways of minimise such limitations:
a) This attachment is a set, which needs concrete setup, we could
change it to a list, and take advantage of
Attachable#addToAttachmentList(...), which inits the attachment list
on demand. AFAIK the change from set to list would not be an issue,
cause duplicated entries in this list would be MSC filtered/ignored
(anyway we could always introduce Attachable#addToAttachmentSet(...)).
In the case this has no side effects, we could even move the remaining
logic of the processor to JndiNamingDependencyProcessor and remove it.
b) Move the Processor to an earlier phase, to ensure the attachment
set is already setup.
Opinions?
-- E
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev