October 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Generic properties on interface and impl class

by scott.stark＠jboss.org

There is no isVolatile in the java.lang.reflect.Method interface, but there is an isBridge() method. I would guess the modifiers bit mask has the Modifier.VOLATILE set for a bridge method, but have not checked that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100415#4100415 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100415

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generalizing supply/demand

by alesj

Can't we/they simply re-write those mbean to MC beans? I'm in favor of encouraging people to use MC beans where ever possible, even if that means rewriting some code. Demand already is a simple DependencyItem. And I just extended it with some 'matching' notion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100414#4100414 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100414

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generic properties on interface and impl class

by alesj

"wolfc" wrote : We should not have a isVolatile on MethodInfo, but isBridge. In theory it can change in the future. No, isVolatile is legit. Perhaps we can add isBridge, which would currently just call isVolatile for MethodInfo. Once 'bridge' can be referenced via JDK, then we can change the impl. | // Bits not (yet) exposed in the public API either because they | // have different meanings for fields and methods and there is no | // way to distinguish between the two in this class, or because | // they are not Java programming language keywords | static final int BRIDGE = 0x00000040; | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100412#4100412 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100412

17 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - Tomcat GenericPrincipal and JBossGenericPrincipal

by anil.saldhana＠jboss.com

http://anonsvn.jboss.org/repos/jbossas/trunk/tomcat/src/main/org/jboss/we... Our Tomcat layer uses JBossGenericPrincipal to basically tie in some additional semantics like callerprincipal etc to the tomcat caching principal. I am wondering if this is really an hindrance to users who want to plug in their own realms and create their versions of the GenericPrincipal. If our code does an instanceof checks, then that is fine. But if we are casting principals in to JGP, then that is a definite No-No for customization. Thinking out loud. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100401#4100401 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100401

17 years, 1 month

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Unable to connect to JBoss AS

by ssjvackar

PLEASE IGNORE, I ACCIDENTALLY POSTED IN THE WRONG TOPIC. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100208#4100208 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100208

17 years, 1 month

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Unable to connect to JBoss AS

by ssjvackar

Hi I'm trying to access a site running on JBoss AS, but it keeps giving me a 'Unable to connect message' It works when I try to access using: | http://localhost:9090/myApp | But not when I use | http://my.machine.name:9090/myApp | or | http://10.1.6.44:9090/myApp (My IP Adress) | Anyone encountered anything like this before? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100204#4100204 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100204

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Get a list of taskinstances using jpdl- error-local cla

by rwarno

Hi, I go t the same problem but found the reason. It was due to different hibernate related library versions of used on client and server side. Take care that jbossall-client.jar compliant with your jboss version precedes other hibernate library version on your classpath. Regards, Rafal View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100200#4100200 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100200

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generic properties on interface and impl class

by wolfc

"scott.stark(a)jboss.org" wrote : Where is the volatile attribute as it applies to methods defined? I can't find this in the http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf update, nor the updated JLS. | JLS third editition 15.12.4.5 in the discussion footnote. We should not have a isVolatile on MethodInfo, but isBridge. In theory it can change in the future. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100189#4100189 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100189

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: AppClientDeployer

by scott.stark＠jboss.org

So to generically use the Ejb3ClientDeployer, it needs to output the BeanMetaData instead of trying to install it so that the resolving deployer can properly setup the dependencies based on the resolved target. Handlers like the EJBHandler are assuming an ejb3 target, which is not correct in general. The current failure of the ClientENCInjectionContainer to start for most deployments is because of invalid dependency creation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100070#4100070 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100070

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Generalizing supply/demand

by scott.stark＠jboss.org

The current problem with using the ejb3 client deployer as a general client deployer is that its container bean is looking for suppliers of things like a jndi name binding. The problem is that supply/demand is a kernel bean specific notion. It does not show up in the Controller api. It shows up in the KernelController. The problem with this is that the jmx mbean service controller cannot express that its context supply the demans of an mc bean context. So when you have a legacy client application deployment that does not involve ejb3 components, there ends up being nothing to supply the demands of the client container bean. Either supply/demand should just be a type of dependency where a demand maps onto a DependencyItem and supply maps to an alias, or we need the supply/demand notion to show up at the more general ControllerContext/Controller level to allow supply/demand to span different context implementations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100061#4100061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100061

17 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2007