[ https://jira.jboss.org/jira/browse/WELD-335?page=com.atlassian.jira.plugi... ] Stuart Douglas reassigned WELD-335: ----------------------------------- Assignee: Stuart Douglas -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WELD-335?page=com.atlassian.jira.plugi... ] Pete Muir commented on WELD-335: -------------------------------- Patch looks technically, though we should cache this info on the AnnotatedType (I think). However I'm still not convinced by this approach. I am away until Monday, I will mull it over :-) BTW I assume you run the full incontainer test run? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WELD-335?page=com.atlassian.jira.plugi... ] Pete Muir commented on WELD-335: -------------------------------- Thanks Stuart. I thought about this again, and I'm not sure this is the correct approach (making the ID for container generated beans different). I think first we need to write some tests that show where this is a problem, and then address the causes of those failures (i.e. let's adjust a few things, rather than throw everything out and start again). The reason I came to this conclusion is that there is no way I can see that someone would actually try to reuse the id of a built in bean - the only case when this happens is if you wrap a container generated bean, in which case you would need to implement PassivationCapable yourself, and hence provide a *different* id. If you didn't, your wrapper wouldn't forward calls to id. It would to equals and hashcode, hence the need to identify where we are mapping stuff incorrectly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WELD-335?page=com.atlassian.jira.plugi... ] Pete Muir commented on WELD-335: -------------------------------- Good point :-) Needs more thought... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WELD-335?page=com.atlassian.jira.plugi... ] Pete Muir commented on WELD-335: -------------------------------- Ok, this sounds like a good approach. Do you want to prototype it, see if you can come up with a decent "diff" algorithm that is efficient? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WELD-335?page=com.atlassian.jira.plugi... ] Pete Muir commented on WELD-335: -------------------------------- Yeah, this is my concern with all these schemes... My gut feeling is that we are missing something obvious. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WELD-335?page=com.atlassian.jira.plugi... ] Stuart Douglas commented on WELD-335: ------------------------------------- I think we also need to add the bean deployment archive id onto the bean id to deal with the case where the same class is deployed inside multiple bean deployment archives, although that probably deserves its own issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WELD-335?page=com.atlassian.jira.plugi... ] Pete Muir commented on WELD-335: -------------------------------- Thanks Stuart, this looks a good approach. I've done significant changes to the patch including tidy up of generic usage, consistent code style, rename of some classes and methods and committed, please review. Beans already have the archive in which they are encoded into their id (see line 49 of RIBean where we add the manager id to the id string), so that is already correct. For this reason I've removed the comparison of bean class, as it is redundant. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WELD-335?page=com.atlassian.jira.plugi... ] Stuart Douglas commented on WELD-335: ------------------------------------- It should be possible to keep the simple id's if the bean is vetoed, however it probably would not be pretty. Also if a bean was vetoed and then two different beans of the same class type were added through the SPI then you could not use the simple id, as it would be random as which one get the simple id an which one gets the complex one. The id's for producer fields etc still have to be fixed up in a similar manner. After thinking about it a bit more complex id should probably only include annotations that have meaning to weld. I have a portable extension that adds a Synthetic bean id annotation to it's AnnotatedTypes, so it can identify them in the ProcessInjectionTarget event. This approach now breaks replication, as the synthetic Id's are non deterministic. This is probably not something that many people will run into, so I don't know if we should worry about it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WELD-335?page=com.atlassian.jira.plugi... ] Pete Muir commented on WELD-335: -------------------------------- Regarding ids added by extensions - making sure these are deterministic isn't really something Weld can help with, except adding a note to the FAQ / guide for extension developers IMO. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WELD-335?page=com.atlassian.jira.plugi... ] Pete Muir closed WELD-335. -------------------------- Resolution: Done Marking resolved, I think Stuart has finished the work. Stuart, please make a new issue if there is still stuff to be done, specifically for those changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira