Thanks for Stephen and Niclas' comments. I have always appreciated the responds from the avalon list.
FYI, I am trying to generate xinfo files for the fulcrum.security.hibernate classes by adding @avalon tags to these classes directly. You may see org.apache.fulcrum.security.hibernate.HibernateGroupManagerImpl and org.apache.fulcrum.security.spi.AbstractGroupManager for details.
--- Stephen McConnell <[EMAIL PROTECTED]> ????> > (of course empty service() or compose() methods may be declared, but
that's like cutting toes to fit the shoes).
I like the expression! But I don't agree with the
sentiment. If I have an abstract class the dependency declarations at the
level are relative to the abstract class. Dependencies declared in a
derived class are relative to the derived class and will accessed
(normally) via an overriding service method in the derived class.
/** * @avalon.dependency type="Widget" key="widget" */ public void service( ServiceManager mgr ) throws ServiceException { super.service( mgr ); Widget widget = mgr.lookup( "widget" ); }
Some examples I have seen have the following arrangement:
public void service (ServiceManager mgr) throws ServiceException { this.sm = mgr; }
public void someMethod () { Block b = (Block) this.sm.lookup ("name"); }
I've seen examples like this as well. Frankly its the sort of thing that leads to trouble. Instead of taking care of your own problem in the space where the problem is occurring - what this actually does is bind you to the underlying abstract class implementation. When your system gets bigger - this turns out to be a RPITA. Instead it is so much better to push the abstract class out into a service provider. Its better for the abstract class (its implementation can change without breaking all of the derived classes) - and its better for the extended class because (a) you contacts are real contracts, and (b) you have the option can plug-in alternative providers.
In this case, wouldn't it make sense to declare @avalon.dependency for someMethod() instead of service()? Or is this a bad coding practice?
It makes presumptions about how is service is used. The container is specifically concerning with the questions:
(a) how to supply dependencies (b) what dependencies to include
The current approach of assigning the @avalon.dependency against the service method makes sense because this is the point where the container interacts with the component. If for example we were to allow a service manager via a constructor argument, the the @avalon.dependency would need to be declared against a specific constructor.
Relative to "where" we then have the question of what goes into the service manager. This is resolved by collecting the set of tags under the specific access point. Collectively those tags make up the definition of the service manager to be supplied at that access point.
2. Wouldn't it be better to have the option of
putting the dependency
declaration under class level javadoc, so that all
major avalon
related tags are collected together?
Technically - its probably possible, however - there
is a problem if you want to take advantage of tags to generate enhanced
javadoc information. In this case you really want the declaration
associated with the subject it is qualifying (class, constructor,
method, etc.).
This also ties in tag scope verification with javadoc generation.
Agree.
3. If it is a must-have requirement to have
@avalon.dependency under
these methods only, wouldn't it be nice to
document it somewhere?
(Or maybe I have missed it?)
Have you see this page:
http://avalon.apache.org/meta/tools/tags/index.html
I have looked at this link and Niclas' suggestion. I see that both examples put @avalon.dependency along with the service() method. I thought that only means that it's a method level tag. Maybe it's just me.
I just checked the doc - and its wrong. It shows the method as a class level scope when in fact is method level and specifically related to the serviceable interface access point (although I've also been playing with a constructor based variant).
I have been pulling my hair for a few days because
maven avalon:meta
wouldn't generate the xinfo files correctly due to
this setup. I am
sure others like me would face the same problem.
We will really
appreciate if this problem can be solved. :)
Thanks.
My immediate impression is that some enhancements
related to tag verification would address the main issue. For
example - during tag assessment a invalid tag should generate a useful
error message stating that the tag is declared outside of a recognized
scope.
That would be great!
A enhancement request has been filed in JIRA. http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=AMETA-1
BTW, I am facing a problem where Merlin 3.2.5 would not process the <component><dependencies><dependency/> key-source association if the dependency declaration in xinfo does not contain the key attribute. i.e.
-- block.xml -- <component name="hello" class="tutorial.HelloComponent"> <dependencies> <dependency key="primary" source="gloria"/> <dependency key="secondary" source="nancy"/> </dependencies> </component>
-- xinfo --
<type> <info> <name>simple</name> <version>1.0.0</version> <lifestyle>singleton</lifestyle> <collection>hard</collection> </info> <dependencies> <dependency type="tutorial.Identifiable"/> <dependency type="tutorial.Identifiable"/> </dependencies> </type>
-- end --
On the other hand, the avalon:meta goal would not
generate the key attribute if (key.equals (type)).
That's because its redundant information. If the key attribute is not defined the key defaults to the value of the type attribute.
However, most of the old components use the component class name as key. As a result, it is a bit inconvinent to use old components in merlin without either editing xinfo by hand or modifying the component to use something else as key. i.e., in HibernateGroupManagerImpl:
/** * @return Returns the persistenceHelper. */ public PersistenceHelper getPersistenceHelper() throws DataBackendException { if (persistenceHelper == null) { persistenceHelper = (PersistenceHelper)resolve(PersistenceHelper.ROLE); } return persistenceHelper; }
Any advice for this problem? Thanks again!
Leaving out the key declaration in the xinfo is equivalent PersistenceHelper.ROLE assuming of course that PersistenceHelper.ROLE actually refers to the PersistenceHelper interface.
Stephen.
Mandr
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
