September 2007 - jboss-dev-forums

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Deployer Changes for AOP

by adrian＠jboss.org

Your commit is incomplete. There's also conf/bootstrap-repo-beans.xml and some other places in the system and testsuite tests that reference the temp.AspectDeployer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082165#4082165 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082165

18 years, 7 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Deployer Changes for AOP

by kabir.khan＠jboss.com

This has been done View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082150#4082150 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082150

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep

by sacha.labourey＠jboss.com

"adrian(a)jboss.org" wrote : | Why did you release 2.0.0.Beta4 without first a snapshot of the latest stuff in jboss-head? | This will have to wait until RC1 now :-( Should we fix those and re-do a new beta ASAP? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082149#4082149 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082149

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep

by kabir.khan＠jboss.com

I have made the switch to use the AspectDeployer from AOP http://jira.jboss.com/jira/browse/JBAS-4537 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082148#4082148 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082148

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | That's why I've always advocated doing the jndi binding via a real registry | which would know the cross reference between the context providing the binding | and its real name. | | | | @JNDIBinding(name="java:/whatever") | | public MyService {} | | | | Where @JNDIBinding adds an advice to the controller context that registers | with the jndi registry the cross reference between the binding and real name. | | Then a JNDIDependencyItem does something like: | | | public boolean isResolved() | | { | | Object realName = jndiRegistry.getRealName(jndiBinding); | | if (realName != null) | | { | | setIDependOn(realName); | | setResolved(true); | | } | | return super.isResolved(); | | } | | | | Now the iDependOn is set, we know when the providing service is removed | so we need to be removed/recycled. | In practice, as I discussed with Carlo, it is more difficult for ejb(3) since you can actually depend on is the "ejb-link-ref-name", resource-ref-name, etc. not the jndi name. Only when the application providing the link is deployed do you know what the real jndi name is. This is something that could be resolved either by 1) a seperate registry/dependency item for links provided by the javaee deployers/containers or 2) a more complicated jndi registry that understands deployments/links and their contexts. I think (1) is easier and cleaner. But the devil is always in the details. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082140#4082140 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082140

18 years, 7 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - JEE5 application.xml directive "library-directory" broken on

by arougthopher

I have been deploying a EAR on JBoss 4.2 using the JEE5 application.xml directive "library-directory" so that my shared libraries are made available to all my ejbs, sars, and wars within the application. Worked great. Tried to move to JBoss 5, and deploy the exact same ear, but I get ClassNotFound exceptions all over the place. I did notice that the EARDeployer was modified slightly, but was wondering if anyone else has seen this issue or has had similar problems? I did not see a bug report for it, though. TIA paul View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082127#4082127 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082127

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | More importantly, you don't know when the jndi binding disappears without the | naming events! That is unless the you can resolve the jndi binding to a real controller context name, i.e. update the iDependOn from "UNKNOWN" to the context name that provides it. That's why I've always advocated doing the jndi binding via a real registry which would know the cross reference between the context providing the binding and its real name. | @JNDIBinding(name="java:/whatever") | public MyService {} | Where @JNDIBinding adds an advice to the controller context that registers with the jndi registry the cross reference between the binding and real name. Then a JNDIDependencyItem does something like: | public boolean isResolved() | { | Object realName = jndiRegistry.getRealName(jndiBinding); | if (realName != null) | { | setIDependOn(realName); | setResolved(true); | } | return super.isResolved(); | } | Now the iDependOn is set, we know when the providing service is removed so we need to be removed/recycled. A poor man's way to do it would be add an alias to the context that represents the jndi binding and use the controller itself as that registry. e.g. psuedo code | ControllerContext ctx = new ServiceControllerContext("jboss.jca:service=DataSourceBInding,jndiName=DefaultDS"); | ctx.setAlias("java:/DefaultDS"); | But then its more difficult to implement the hypothetical valve processing where you differentiate dependency injection from the public entry points. i.e. the advice that also implements the jndi binding to the registry can also trigger the valve advice that waits for in flight requests to finish before allowing undeployment/stop(). But like I said, the valve advice is hypothetical. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082115#4082115 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082115

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : The kernel registry plugin just provides a bridge from kernel registry to jndi registry. What if JNDI isn't populated yet? There's no way resolve the dependency afterwards. It will ask to resolve it again the next time you deploy something to the controller. More importantly, you don't know when the jndi binding disappears without the naming events! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082111#4082111 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082111

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by bill.burke＠jboss.com

Lol, we don't implement javax.naming.event View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082105#4082105 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082105

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by bill.burke＠jboss.com

The kernel registry plugin just provides a bridge from kernel registry to jndi registry. What if JNDI isn't populated yet? There's no way resolve the dependency afterwards. I'll look at javax.naming.event. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082093#4082093 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082093

18 years, 7 months

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 September 2007