March 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Registering listener on KernelEventManager

by adrian＠jboss.org

P.S. This example also needs an unregister listener to avoid memory leaks and allow reboots of the server without halting the JVM. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137328#4137328 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137328

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Registering listener on KernelEventManager

by adrian＠jboss.org

"alesj" wrote : "alesj" wrote : | | Probably securely getting it off the target is what we need to do. | | | | | // this already checks for permission | | return target.getClass().getClassLoader(); | | No. target.getClass().getClassLoader() is not correct (and is pretty much always wrong). The TCL would be better, but not in the case. The correct classloader (like all the other installs) is to use the classloader of the bean doing the install. Otherwise how could this work if you used the classloader where the KernelEventRegistry is located (i.e. the bootstrap classloader/classpath) | <deployment xmlns="urn:jboss:bean-deployer:2.0"> | <classloader></classloader> | <bean name="StartupMonitor" | class="org.jboss.test.profileservice.lib.startup.StartupMonitor"> | <install bean="jboss.kernel:service=KernelEventManager" method="registerListener"> |  | <parameter>jboss.kernel:service=KernelEventManager</parameter> | <parameter><this/></parameter> | <parameter><null/></parameter> | <parameter><javabean class="from.my.classloader"/></parameter> | </install> | </bean> | </deployment> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137326#4137326 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137326

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving to CR1 releases of the MC projects

by adrian＠jboss.org

I also don't see feature requests for ControllerMode == asynchronous (requested by Bela) or the error handling mechanism (requested by Tom) We should add api for these even if we don't implement them in 2.0.0.GA That way they can be implemented in 2.0.X e.g. we can automatically change asynchronous to automatic until it is done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137323#4137323 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137323

18 years

1
0
0 / 0

[Design of JBossXB] - Re: Extending EnumValueAdapter

by alesj

"adrian(a)jboss.org" wrote : | The user shouldn't have to write code for this feature when it can | be made declaritive. Sure. But I didn't want to bloat EVA, with all the string handling code. Since this only applies if the key is pure string. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137321#4137321 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137321

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Kernel module wip WARNING

by adrian＠jboss.org

"alesj" wrote : OK, I think a WARNING here should be enough. | Despite this: | "adrian(a)jboss.org" wrote : | | Fair warning is a message to the dev-list with a title that has block capitals | | and an explanation of what people need to do to get the correct behaviour. | :-) | I was talking about changes that effect the appserver (like your removing of part of the api without replacement :-). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137320#4137320 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137320

18 years

1
0
0 / 0

[Design of JBossXB] - Re: Extending EnumValueAdapter

by adrian＠jboss.org

"alesj" wrote : An 'issue' I stumbled upon today, perhaps being worth a new feature. | It would be cool if we could make EnumValueAdapter be case unaware for String keys. | Probably the best way to impl this is to extend EVA, where we before provide proper hooks. | And the user than sets this as a ValueAdapter for his enum. | | What do you think? | | ps: I've already got a working impl locally :-) Just do something like | @JBossXmlEnum(ignoreCase=true) | public enum MyEnum {} | Then when constructing the map of valid values and doing the lookups convert the xml values to lower case if the "ignoreCase" is true. The user shouldn't have to write code for this feature when it can be made declaritive. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137317#4137317 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137317

18 years

1
0
0 / 0

[Design of JBossXB] - Re: Extending EnumValueAdapter

by adrian＠jboss.org

"alesj" wrote : An 'issue' I stumbled upon today, perhaps being worth a new feature. | It would be cool if we could make EnumValueAdapter be case unaware for String keys. | Probably the best way to impl this is to extend EVA, where we before provide proper hooks. | And the user than sets this as a ValueAdapter for his enum. | | What do you think? | | ps: I've already got a working impl locally :-) Just do something like | @JBossXmlEnum(ignoreCase=true) | public enum MyEnum {} | Then when constructing the map of valid values and doing the lookups convert the xml values to lower case if the "ignoreCase" is true. The user shouldn't have to write code for this feature when it can be made declaritive. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137315#4137315 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137315

18 years

1
0
0 / 0

[Design of JBoss Tools (dev)] - Re: Seam support in the JSP editor

by Neeraj Bhatt

I am in the process of doing similar type of task. We are working on WTP 3.0 M4 JSF editor. Through extension points we have enhanced context menu in the relevant JSF components to browse beans and bean properties . Once you select these beans/bean properties the underlying JSF code changes automatically. Also we have given option in context menu to select transitions from page flow file of seam frame work. We have created our own extension points to give above functionallity but popupMenuContributor extension available in org.eclipse.jst.pagedesigner plugin of WTP can also be used to create context menu in JSF . Although right now popupMenuContributor is having a blocking bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=221197 . I have submitted a patch for this bug ,once it gets commited then popupMenuContributor can be used to give same capabilities. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137310#4137310 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137310

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Registering listener on KernelEventManager

by alesj

"alesj" wrote : | Probably securely getting it off the target is what we need to do. | | // this already checks for permission | return target.getClass().getClassLoader(); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137303#4137303 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137303

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Registering listener on KernelEventManager

by alesj

"scott.stark(a)jboss.org" wrote : | Why wouldn't the event mgr have an InvokeDispatchContext implementation? | At the beginning AbstractKernelRegistryEntry had no notion of dispatch. When I was changing KernelBus I added the attribute dispatch notion to it. Dunno why I didn't add full invoke dispatch. I can do that now, since the BeanKernelRegistryEntry already does have a BeanInfo ref, so adding method invoke is trivial. It's the getClassloader (on InvokeDispatchContext) that is less obvious. Probably securely getting it off the target is what we need to do. I'll commit this during the day, but you should still be aware of this warning: - http://www.jboss.org/index.html?module=bb&op=viewtopic&t=131997 :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137302#4137302 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137302

18 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008