Yes, the reason is that you are overriding a built-in component (or even a user component) with another component.
I do see the value it that. Thx for the reply.
It was in fact a user component that I was unintentionally overriding.
The results were not deterministic. On redeploy it seemed that one was being set, but on restart of the app server the one I was trying to use was being looked up.
So if I have two user components with the same name and I want to override one of them as to ignore the other as a seam component.
How do I specify which will take precedence?
There was a recent fix in CVS for #JBSEAM-111 to issue a "warn" level logging message if 2 components are registered with the same name.
There is no provision to specify precedence... But I am interested to know why you want to override a component?
Good question, there is currently no well-defined precedence.
Feel free to add this to JIRA...
I do not currenly want to do this, but in the future I might.
For example what if I have a jar that includes an assortment of SLSB, SFSB, an and entites with @Name that gives a unit of functionality to my application for user and role management.
I might want to drop this jar into another ear for another application and have this funtionality already in place and just replace the components that need special logic.
I have not looked into this so there could be another way.
Please define new. If there are two components with the same name are deployed in the same ear which is considered new?
As of today, there is no way to tell Seam which one to pick first.
What i meant is that from the log you can tell which one is being used. (This is just informative that something is wrong)
Here is a log sample with two components named "booking". The latest replace the previous one picked by the scanner.
11:21:38,850 INFO [Scanner] scanning: /home/theute/jboss-5.0.0.Alpha/server/default/tmp/deploy/tmp53108jboss-seam-booking.ear-contents/jboss-seam-booking.jar 11:21:38,962 INFO [Component] Component: hotelSearch, scope: SESSION, type: STATEFUL_SESSION_BEAN, class: org.jboss.seam.example.booking.HotelSearchingAction, JNDI: jboss-seam-booking/HotelSearchingAction/local 11:21:39,058 INFO [Component] Component: changePassword, scope: EVENT, type: STATEFUL_SESSION_BEAN, class: org.jboss.seam.example.booking.ChangePasswordAction, JNDI: jboss-seam-booking/ChangePasswordAction/local 11:21:39,061 INFO [Component] Component: user, scope: SESSION, type: ENTITY_BEAN, class: org.jboss.seam.example.booking.User 11:21:39,063 INFO [Component] Component: logout, scope: STATELESS, type: STATELESS_SESSION_BEAN, class: org.jboss.seam.example.booking.LogoutAction, JNDI: jboss-seam-booking/LogoutAction/local 11:21:39,064 INFO [Component] Component: hotelBooking, scope: CONVERSATION, type: STATEFUL_SESSION_BEAN, class: org.jboss.seam.example.booking.HotelBookingAction, JNDI: jboss-seam-booking/HotelBookingAction/local 11:21:39,073 INFO [Component] Component: hotel, scope: CONVERSATION, type: ENTITY_BEAN, class: org.jboss.seam.example.booking.Hotel 11:21:39,075 INFO [Component] Component: booking, scope: CONVERSATION, type: ENTITY_BEAN, class: org.jboss.seam.example.booking.Booking 11:21:39,078 INFO [Component] Component: register, scope: EVENT, type: STATEFUL_SESSION_BEAN, class: org.jboss.seam.example.booking.RegisterAction, JNDI: jboss-seam-booking/RegisterAction/local 11:21:39,080 INFO [Component] Component: login, scope: STATELESS, type: STATELESS_SESSION_BEAN, class: org.jboss.seam.example.booking.LoginAction, JNDI: jboss-seam-booking/LoginAction/local 11:21:39,082 WARN [Initialization] Component with name booking has been previously registered and is being redefined. 11:21:39,083 INFO [Component] Component: booking, scope: SESSION, type: STATEFUL_SESSION_BEAN, class: org.jboss.seam.example.booking.BookingListAction, JNDI: jboss-seam-booking/BookingListAction/local
What would be a good strategy for you ?
What do you think about a configuration in components.xml that would force a component to be used if declared there?
I haven't played with any advanced config using components.xml but I understand from the doc that you can use it to create a Seam component from a class that doesn't have to be annotated with @Name.
Would it work in your example to leave @Name off anything reusable you include in your jar and install them into your application this way?
I would rather not leave off this annotation.
It would be the default for many of the applications that would use the class.
If I leave it off I would have to put it in every components.xml for every application that used this class instead of the few cases that need an overridding component.
How about an order attribute in components.xml (like the servlet load-on-startup)? The named component in a given scope with the highest order wins. This would allow for the override of not only built-in components but others as well.
Assume for the sake of argument that some contributor creates a component suite that overrides certain seam built-in components (to provide security, spring integration, whatever). Later on you, or someone else develops a new component X to override component X in the contrib suite. The contrib suite is made up of components X, Y, Z. It's desirable for both jars to be included in the system and for the newest component X to override both the original contrib and built-in component.
This isn't a perfect system because is relies on the component packager to choose priority. However this probably isn't a major issue and a single drop in jar is easier on the users than requiring additional configuration.
If this were the default I think we'd get pretty far. For the edge case were you have many components overriding (possibly incorrectly) we could specify an additional top level configuration (web.xml or seam.properties?) that overrides the order for a given class. Sensible defaults + overrides if necessary. It sounds good to me, but does this really need to be taken to the Nth degree or could something less complex work just as well?
I like the idea where if the component is defined in component.xml, it overrides the default Seam scanning.
So CptnKirk, like you imply in your post, you only want to end up with a single X component being managed by Seam - this would be the one defined in components.xml.
Order-by doesn't seem intuitive to me because of the fact that you only want to know about that single X component in the end - unlike servlets where execution order can be important.
We can still override built in components using the class attribute.
I'm happy to make these changes and commit them.