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

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP ClassLoader/Scoping needs thoroughly revising

by adrian＠jboss.org

The issue as it appears to me in the AOP config is that it is generally storing things at the class(loader) level. This is a reasonable strategy to avoid memory leaks. Once the class(loader) is GCed the WeakReference is removed. But in general this leads to the wrong configuration or wrong advices getting used. What is required is a different strategy where *logically* the advice stacks (and other info?) are at the scope/class level. Of course, we should still need to optimize away duplicates where there is no override at more finer grained scopes. If it just took the simplistic approach then you have an advice stack per instance which wouldn't scale at all. :-) I'm not sure what the best way to implement this is efficently. You obviously don't to be doing a scope access on every method/field call to see whether there is an override for that scope. And in fact, that might lead to wrong semantics where an object from one application is passed to another application. It could suddenly start using the wrong advices. That is why I emphasised "logically" above. It seems to me that the best way to do this would be like MC instance level aop. That is if the config/advices/class are all in the same scope/domain then we just need a normal Advisor. If however we are going to override a class's configuration in a child scope/domain (maybe even the class is not advised in its own scope) then we use the proxy stuff like the MC work. Finally, the other advantage of using Scopes when they are integrated into the deployers is that there is a pretty trivial point during the undeploy when you know the information can be released and what information needs to be released. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060871#4060871 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060871

18 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS 2.1 embedded?

by thomas.diesler＠jboss.com

We currently rely on the standard JavaEE deployment model, which binds us to the AS. We used to have a Tomcat porting layer, which we dropped because of too little community interest. Eventually we would like to extend the JAXWS Endpoint.deploy() API to other target containers (i.e. Jetty). This however is still a todo. http://jira.jboss.org/jira/browse/JBWS-1728 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060862#4060862 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060862

18 years, 9 months

1
0
0 / 0

[QA of JBoss Portal] - Re: SSO Unit Testing

by sohil.shah＠jboss.com

Basically we will need a different unit test environment for different SSO Frameworks being integrated. Our first framework integration in experimental stage has been CAS. See here was environment setup details: http://wiki.jboss.org/wiki/Wiki.jsp?page=CASSSOFrameworkIntegration Here are my initial thoughts on what is needed for testing the CAS integration 1/ A CAS web application instance with the JBoss Portal Authentication Handler integrated as mentioned in the wiki. (This would probably need to be via loading tomcat as a service inside microcontainer) 2/ From Portal standpoint, we probably just need a very simple web application with the CAS Valve installed (loaded along with the CAS server in the microcontainer as well) 3/ We will need to load the JAAS service that takes care of the Portal authentication in the microcontainer as well. Note: Looks like points 2 and 3 will be common across all SSO integrations while point 1 will vary depending on SSO Framework in question Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060860#4060860 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060860

18 years, 9 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP ClassLoader/Scoping needs thoroughly revising

by adrian＠jboss.org

Of course, I still need to integrate the MetaDataRepository into the deployers such that each DeploymentUnit or Component has its own MetaData scope. i.e. each deployment will have a unique MutableMetaData in a scope determined by the relevant deployer that AOP can populate. That is number 4 on my list of things to do, so it is not going to get done straight away. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060857#4060857 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060857

18 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - JBossWS 2.1 embedded?

by thomas.diesler＠jboss.com

Jonathan sais: I'm giving some thought to the design of our functional test suite for JBossTS XTS i.e. Web services transactions. I'd like to follow the same model as we use for JBossTS JTS, where each test runs in its own JVMs. That means a lot of starting and stopping containers! I've been experimenting with Jetty, which has a ~5second startup time for XTS, against 45-60seconds when running XTS inside JBossAS. Which brings me to the question... to what extent will JBossWS 2.1 rely on JBossAS? Can it be run under any servlet container, or does it need AS specific services? How about using JBoss Embedded? I know AXIS will run happily in Jetty, but I've not tried CFX or Metro. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060855#4060855 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060855

18 years, 9 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP ClassLoader/Scoping needs thoroughly revising

by adrian＠jboss.org

So what I'm getting at is that just determining the aop advices from the classloader of the advice or the advised class is not enough. What is really required, is for aop to use some notion of scope so it knows what server/subsystem/deployment/class/instance it is working with. I'm not asking for aop to implement anything related to scope (it already exists in fact see below), but what we need is a mechanism where the correct scope is used in each case. An integration api (to replace AOPScopedClassLoaderHelper) might be something as simple as: | public interface DomainContextFactory | { | // Get the domain from the current context (e.g. a thread local) | Domain getDomain(); | | // Get the domain for a specific scope | // Not sure if you really need this but you have a getTopLevelClassLoader() | // in the old api - not sure what is for? | Domain getDomain(Scope scope); | } | You might have guessed from the signature that I'm suggesting using the MetaDataRepository as the implementation of this api inside JBoss. The idea being that a Domain can be added to different scopes and populated by the AOPDeployer(s). e.g. the default scope (what is currently now the AspectManager) would be something like (pseudo code - not the real api for simplicity) | MetaData md = MetaDataRepository.getScope(ScopeLevel.JVM, "Instance"); | Domain domain = rep.getMetaData(Domain.class); | The first method in the proposed api would be implemented as (assuming the callers have setup the correct scope context) | MetaData md = MetaDataStack.peek(); | Domain domain = rep.getMetaData(Domain.class); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060854#4060854 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060854

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Tracking WF path of execution

by estaub

"kukeltje" wrote : Wouldn't it be better if we just added a hook in the code where an external event-listener can be attached (configuration), or make it possible to e.g. register a global eventlistener (event='any' on the processdefinition) | | Here here! I believe this is all that would be necessary in the engine to also support (remote) debugging, which is a future goal for us. In other words, from a "workflow debugger UI", someone could single-step through a workflow, let it run and watch where it goes, set breakpoints in it, etc. -Ed Staub View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060852#4060852 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060852

18 years, 9 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP ClassLoader/Scoping needs thoroughly revising

by adrian＠jboss.org

Use case: "subsystem" aop config We already have a concrete version of this in EJB3 where the EJB3 containers have a specific domain for the aop config. But it is a hardwired implementation with no general support for this feature to be used by other subsystems Use Case 1: Adding advices for the JCA stack I already prototyped a version of the JCA stacks through AOP. e.g. You can define what behaviour to add in front of the jdbc api for the jdbc outbound rar but again this is a hardwired use of domains. The key thing here is that we want the JCA advices (pooling, security, transaction enlistment) only for the outbound jdbc rar. We don't want these advices to apply to none JCA usage of jdbc. Use Case 2: Different JCA stacks at the deployment level The JCA stacks could actually be deployment specific themselves. e.g. there is a local-jdbc.rar and an xa-jdbc.rar which have different requirements Use Case 3: Differfent JCA stacks at the instance level The JCA stacks could even change for a specific data-source deployment in a -ds.xml That is for this datasource only I want to add to or change the advice stack. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060851#4060851 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060851

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Portal build

by chris.laprun＠jboss.com

"julien(a)jboss.com" wrote : The current status is: | | - we use buildmagic | - it works | - everybody knows how to use it | But it's difficult to understand and extend. Then again, if it works... There's someone in the community who started to look at using Maven to build but I'm not sure what the status is. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060848#4060848 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060848

18 years, 9 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP ClassLoader/Scoping needs thoroughly revising

by adrian＠jboss.org

Use case: ClassLoader (really class location) versus deployment scoping The requirement here is that all deployment situations that should work will work as expected. Typically there are three items in the mix (I'll explain the AOP terminology as well for those readers that are not familiar with it) 1) The class being "modified" (I'll call this the "advised class"), e.g. this would be Oracle's Connection class 2) The advice (or interceptor if you like) which is the what "modification" you want to make to the class 3) The configuration, i.e. what are the advices, to which classes do they apply and where in that class they are made (called joinpoints in AOP) The use case comes when these are not all in the same deployment or you want to do different things in different deployments. e.g. Use Case 1: Different advices in different deployments Suppose I have Oracle's jdbc jar deployed such that everybody can see the classes and I want to advise those classes in different ways in different applications Currently, the advices are linked to the class through what JBoss AOP calls the advisor. That is every joinpoint has a list of advices (could be no list if the joinpoint is not advised). None of those lists can be changed at the deployment level. There is a notion perJVM, perClass, perInstance, but this is more about how instances of the advice you get, not what the advice is or does. e.g. Use Case 2: Different configuration in different deployments This is similar to use case 1, but the advices are classes that are also globally available. But the configuration (the -aop.xml) is different in the different deployments. e.g. Use Case 3: Different advised classes in different deployments Suppose I deploy different Oracle jars in different applications and then specify global/local advices and global/local configuration. This is the kind of thing that will work "out-of-the-box" because there are multiple versions of the classes to add advisors to. e.g. Use Case X: Other variants There are other variants some of which may or may not make sense, but those that do are probably unlikely to work just by looking at the classloader of the advised class or advice to determine what configuration to use. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060847#4060847 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060847

18 years, 9 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 July 2007