[Design the new POJO MicroContainer] - Re: Anonymous beans
by alesj
"adrian(a)jboss.org" wrote :
| Why are you "cloning" fields that are direct referenes? What does it achieve?
|
You mean immutables?
Does Object::clone do that already for me?
"adrian(a)jboss.org" wrote :
| This looks overally complicated and an obvious misuse of generics again.
| Why have generics then do all the casting and suppress warnings?
|
| The way to clone collections is something like:
|
|
| | Set<String> aliases = this.getAliases();
| | if (aliases != null)
| | clone.setAliases(new HashSet<String>(aliases));
| |
All would be fine if Object::getClass returned the right Class generic. :-)
I don't wanna do that extra 2 lines (null check and the new collection instantiation) for every cloning of the collection.
And I guess I would also have to iterate over all the collection items that are not immutable and clone them before adding them to new collection instance.
Another code that I don't want to duplicate.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142111#4142111
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142111
18 years
[Design the new POJO MicroContainer] - Re: Anonymous beans
by adrian＠jboss.org
"alesj" wrote :
|
| | public Object clone()
| | {
| | AbstractBeanMetaData clone = new AbstractBeanMetaData();
| | doClone(clone);
| | return clone;
| | }
| |
|
No you should use covariant return types
| public AbstractBeanMetaData clone()
| {
| ...
| }
|
anonymous wrote :
|
| | protected void doClone(AbstractBeanMetaData clone)
| | {
| | super.doClone(clone);
| | clone.setBean(bean);
| | clone.setName(name);
| | clone.setAliases(aliases);
| | ...
| | }
| |
|
Why are you "cloning" fields that are direct referenes? What does it achieve?
anonymous wrote :
| Do we already have some similar code, to clone collections:
|
| | @SuppressWarnings("unchecked")
| | public static <U extends JBossInterface, T extends Collection<U>> T clone(T collection)
| | {
| | if (collection == null)
| | return null;
| |
| | try
| | {
| | Class<? extends Collection> collectionClass = collection.getClass();
| | T clone = (T)collectionClass.newInstance();
| | for (U item : collection)
| | clone.add((U)item.clone());
| | return clone;
| | }
| | catch (Throwable t)
| | {
| | throw new RuntimeException(t);
| | }
| | }
| |
This looks overally complicated and an obvious misuse of generics again.
Why have generics then do all the casting and suppress warnings?
The way to clone collections is something like:
| Set<String> aliases = this.getAliases();
| if (aliases != null)
| clone.setAliases(new HashSet<String>(aliases));
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142107#4142107
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142107
18 years
[Design of JCA on JBoss] - Re: JBAS-5278 Errors .
by jesper.pedersen
Hi Adrian.
Currently JBossMessaging doesn't have its own ResourceAdaptor as you know.
JBossMessaging is being deploy in EAP as the default messaging provider together with the current JCA/JMS adaptor. This results in errors in the testsuite like JBPAPP-750.
For AS-5.0 and EAP-4.3 I'll help the messaging team by providing the ResourceAdaptor as you describe - and later we should provide an optimized version using the internal API.
Also we should use all your ideas from the jboss-jca project and in JIRA for a new implementation of the JCA specs for the next version of the AS.
But if requirements for the EAP platform is only to use JBossMessaging for its messaging implementation we can go directly to the internal API implementation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142095#4142095
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142095
18 years