-
1. Re: Moving microcontainer -> kernel
dmlloyd May 26, 2009 6:21 PM (in response to kabirkhan)While you're going through the API to do this refactor, it might be a good time to change all the parameters which represent a bean name from being "Object" to "String".
Or maybe that's a can of worms... -
2. Re: Moving microcontainer -> kernel
alesj May 27, 2009 2:59 AM (in response to kabirkhan)"david.lloyd@jboss.com" wrote:
While you're going through the API to do this refactor, it might be a good time to change all the parameters which represent a bean name from being "Object" to "String".
Isn't this already the case on BeanMetaData?
Doing this elsewhere would be wrong,
as you don't really know or care what kind of type do other components use for their name. -
3. Re: Moving microcontainer -> kernel
dmlloyd May 27, 2009 8:38 AM (in response to kabirkhan)"alesj" wrote:
"david.lloyd@jboss.com" wrote:
While you're going through the API to do this refactor, it might be a good time to change all the parameters which represent a bean name from being "Object" to "String".
Isn't this already the case on BeanMetaData?
Doing this elsewhere would be wrong,
as you don't really know or care what kind of type do other components use for their name.
Of course you do. The name is a String so why support anything else? And even if you do decide to support something like ObjectName or whatever, you should use overloading for that purpose. It doesn't make sense to allow Object. It implies that I can pass in a HashMap, or a Socket, or an AudioFileFormat, or ... -
4. Re: Moving microcontainer -> kernel
kabirkhan May 27, 2009 9:17 AM (in response to kabirkhan)"ALR" wrote:
Will you please follow up, when complete, with the complete:
groupId:artifactId:version
...of all the projects affected, as well as their old names?
Likely we'll want to be adding some rules to the various Enforcer Plugin configurations to ban the old stuff.
S,
ALR -
6. Re: Moving microcontainer -> kernel
alesj May 27, 2009 11:31 AM (in response to kabirkhan)"david.lloyd@jboss.com" wrote:
Of course you do. The name is a String so why support anything else? And even if you do decide to support something like ObjectName or whatever, you should use overloading for that purpose. It doesn't make sense to allow Object. It implies that I can pass in a HashMap, or a Socket, or an AudioFileFormat, or ...
No I don't. ;-) The name is definitely not just a String.
Although I see where you're aiming, but there is more to it then just overloading.
And exactly the notion of having no explicit type is what makes it possible to:
* handle contextual injection with a single lookup method
* support Guice Key and other impl details
* legacy ObjectName as key/name
* ...
And if AudioFileFormat makes you happy, be my guest. :-) -
7. Re: Moving microcontainer -> kernel
dmlloyd May 27, 2009 2:21 PM (in response to kabirkhan)OK, I may not agree that this is "right" but it is what it is. I think there's one thing we can agree on though - the parameter ought to have a more accurate name, like "beanName" or "beanIdentifier" rather than just "bean", because "bean" implies an expectation that you're passing in the actual bean object in question rather than its identifier.
-
8. Re: Moving microcontainer -> kernel
kabirkhan May 27, 2009 5:11 PM (in response to kabirkhan)"david.lloyd@jboss.com" wrote:
OK, I may not agree that this is "right" but it is what it is. I think there's one thing we can agree on though - the parameter ought to have a more accurate name, like "beanName" or "beanIdentifier" rather than just "bean", because "bean" implies an expectation that you're passing in the actual bean object in question rather than its identifier.
I'm working on improving the javadocs, so that is something I can look into -
9. Re: Moving microcontainer -> kernel
adrian.brock Jun 2, 2009 9:06 AM (in response to kabirkhan)"david.lloyd@jboss.com" wrote:
OK, I may not agree that this is "right" but it is what it is. I think there's one thing we can agree on though - the parameter ought to have a more accurate name, like "beanName" or "beanIdentifier" rather than just "bean", because "bean" implies an expectation that you're passing in the actual bean object in question rather than its identifier.
You simply don't get it.
The controller context, dependencies, etc. has nothing to do with a "bean"
or the choices of any particular component model.
The POJO controller context is only one possible implementation that relates to beans
and that happens to use a String as the name.
Other component models don't have to use a String for the name.
Its up to each component model to keep things consistent.
If you want the longer version of this argument, at least as it relates to JMX, then use
search. I know I've been over the issue at least once before at some length in this forum.
There's even a JIRA (or at least a discussion) somewhere about using a "UUID"
as the real id with the publically visible "name" just being an alias. -
10. Re: Moving microcontainer -> kernel
dmlloyd Jun 2, 2009 10:17 AM (in response to kabirkhan)"adrian@jboss.org" wrote:
"david.lloyd@jboss.com" wrote:
OK, I may not agree that this is "right" but it is what it is. I think there's one thing we can agree on though - the parameter ought to have a more accurate name, like "beanName" or "beanIdentifier" rather than just "bean", because "bean" implies an expectation that you're passing in the actual bean object in question rather than its identifier.
You simply don't get it.
I get it - as I said, it is what it is. I'm just saying that at the least we ought to change the parameter name because it's misleading. For example, BeanMetaDataBuilder gives us:public static BeanMetaDataBuilder createBuilder(String name, String bean)
This just makes no sense. One of those parameters is the name of the bean associated with the BeanMetaData, the other is the name of the class. But which is which? I get it wrong about half the time. -
11. Re: Moving microcontainer -> kernel
adrian.brock Jun 2, 2009 10:32 AM (in response to kabirkhan)"david.lloyd@jboss.com" wrote:
public static BeanMetaDataBuilder createBuilder(String name, String bean)
This just makes no sense. One of those parameters is the name of the bean associated with the BeanMetaData, the other is the name of the class. But which is which? I get it wrong about half the time.
This must be a bad example? The javadoc tells you which is which.
If you posted all the code;/** * Create builder from name and bean. * * @param name bean name * @param bean bean class name * @return new Builder */ public static BeanMetaDataBuilder createBuilder(String name, String bean) { return BeanMetaDataBuilderFactory.createBuilder(name, bean); }
Parameter names have no meaning in java anyway - it being a positional language - so they could be called x and y. This is "Humpty dumpty" again.
"bean" is actually the name of the class on BeanMetaData because you can't have
a get/setClass() - it already means something else in java.lang.Object.
Anyway, "String bean" is kind of funny, even if it wasn't an intentional joke by Ales. :-)
http://en.wikipedia.org/wiki/Green_beans -
12. Re: Moving microcontainer -> kernel
dmlloyd Jun 2, 2009 11:00 AM (in response to kabirkhan)Parameter names do have meaning in that they tell the human reading the code what the parameter is. If you called all your parameters "x" and "y" you'd soon have an angry mob outside your door - or at least, people wouldn't use your hard-to-use software.
If "bean" is the class name, how about "beanName" and "beanClassName"? There's nothing wrong with being descriptive. -
13. Re: Moving microcontainer -> kernel
kabirkhan Jun 4, 2009 1:04 PM (in response to kabirkhan)As advertised the move has now happened. To check out the kernel project, neé microcontainer,
you now check out https://svn.jboss.org/repos/jbossas/projects/kernel/trunk/.
https://svn.jboss.org/repos/jbossas/projects/microcontainer/branches and https://svn.jboss.org/repos/jbossas/projects/microcontainer/tags contain the existing tags and branches for the current releases.
Further 2.2.x releases will be tagged from https://svn.jboss.org/repos/jbossas/projects/kernel/branches/Branch_2_2/, which will be a branch of https://svn.jboss.org/repos/jbossas/projects/kernel/trunk/
https://svn.jboss.org/repos/jbossas/projects/microcontainer/mcdocs contains the documentation, managing its own branches and tags.
https://svn.jboss.org/repos/jbossas/projects/microcontainer/mc-release/ contains the tool for uploading all the mc artifacts to the downloads area, again managing its own branches and tags.
Further projects 'global' to MC should be added under https://svn.jboss.org/repos/jbossas/projects/microcontainer.
The renames of the maven artifacts are as follows. This will only take effect from further 2.2.0 releases:
org.jboss.microcontainer:jboss-microcontainer -> org.jboss.kernel:jboss-mc-kernel (parent)
org.jboss.microcontainer:aop-mc-int -> org.jboss.kernel:aop-mc-int
org.jboss.microcontainer:guice-int -> org.jboss.kernel:guice-int
org.jboss.microcontainer:jboss-dependency -> org.jboss.kernel:jboss-dependency
org.jboss.microcontainer:jboss-kernel -> org.jboss.kernel:jboss-kernel
org.jboss.microcontainer:jmx-aop-mc-int -> org.jboss.kernel:jmx-aop-mc-int
org.jboss.microcontainer:jmx-mc-int -> org.jboss.kernel:jmx-mc-int
org.jboss.microcontainer:spring-int -> org.jboss.kernel:spring-int
If there are more 2.0.x releases they will use the old group ids. -
14. Re: Moving microcontainer -> kernel
dmlloyd Jun 4, 2009 4:06 PM (in response to kabirkhan)BTW if you already have the microcontainer trunk checked out, you don't need to check it out again. Just run this command:
svn switch https://svn.jboss.org/repos/jbossas/projects/kernel/trunk
and you'll be in the new repository.