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

[Design of POJO Server] - Re: Generalizing dependency injection

by wolfc

"adrian(a)jboss.org" wrote : What you are describing is called "flow control". You can do it outside an EJB | with an aspect, e.g. a semaphore controlling access to a singleton. | | If the semaphore/pool uses priority queuing the admin request | can "jump the queue" based on a higher privilege. A pool beats a semaphored singleton anytime. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136403#4136403 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136403

18 years

1
0
0 / 0

[Design of JBoss Portal] - Re: ServletContainer.register(ServletContainerContext contex

by chris.laprun＠jboss.com

Considering that ServletContainer is supposed to be a static registry for ServletContainerContexts (at least according to the javadoc), it seems natural to me that you should be able to register contexts with it. Also, the ServletContainerContext interface makes several references to such a registration (cf. Registration inner interface for example). The register method is used by JBossWebContext in Portal. With the addition of add/removeWebAppListener on ServletContainer, the whole Registration concept seems rather convoluted and seems to make the API more complex than necessary (though I might not have a proper understanding of the big picture). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136402#4136402 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136402

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Notion of 'compatible-version'?

by scott.stark＠jboss.org

"wolfc" wrote : Until we know how Maven handles ranges during its release cycle we should not be using that. | | Suppose the following: | AS 5.0 depends on EJB3 [1.0,2.0) | Current EJB3 release is 1.0. | | Now I release EJB3 1.1. | | How reproducable is the AS 5.0 build? | | The mvn release plugin should be recording the versions used, and that version info committed as part of the tag. The release build should effectively be locked to single versions. How reproducible the trunk/branch build is remains. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136401#4136401 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136401

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM With Seam

by fady.matar

I've been refraining from the implementation of an LDAP module because no matter how generic it won't be generic enough to fit all structures. anonymous wrote : | I think where user/group/identity service should become interfaces in the core. | I totally agree, this has to start with an abstract scheme and could be extended to match all users requirements. JBoss portal has some module for Ldap integration you could have a look or you can even have a look at the JBoss authentication Ldap modules. Cheers, Fady View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136391#4136391 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136391

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Generalizing dependency injection

by adrian＠jboss.org

"wolfc" wrote : OFF-TOPIC :-) | | Suppose I have a data source pool of 100 and I have two session beans which make use of that data source. One performs the search function for end users, the other is the admin interface. | Now I don't want to starve the data source by having 100 searchers active (and more in queue) while the admin is waiting to get anything done. So search bean will be pool limited to 75 and admin will receive similar treatment. | I say EJB 3 is all about resource management. :-) What you are describing is called "flow control". You can do it outside an EJB with an aspect, e.g. a semaphore controlling access to a singleton. If the semaphore/pool uses priority queuing the admin request can "jump the queue" based on a higher privilege. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136390#4136390 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136390

18 years

1
0
0 / 0

[Design of JBoss Build System] - Group and artifact ID's

by heiko.braun＠jboss.com

Are we going to follow a particular scheme for naming the artifacts? It seem like package name usually becomes groupId, but the AS build still follows the way components have been named within the old repo. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136388#4136388 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136388

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Notion of 'compatible-version'?

by heiko.braun＠jboss.com

anonymous wrote : | We already know that our version strings are not interpreted correctly. | What are the problems you did encounter? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136385#4136385 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136385

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Generalizing dependency injection

by wolfc

OFF-TOPIC :-) Suppose I have a data source pool of 100 and I have two session beans which make use of that data source. One performs the search function for end users, the other is the admin interface. Now I don't want to starve the data source by having 100 searchers active (and more in queue) while the admin is waiting to get anything done. So search bean will be pool limited to 75 and admin will receive similar treatment. I say EJB 3 is all about resource management. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136384#4136384 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136384

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Notion of 'compatible-version'?

by heiko.braun＠jboss.com

Acceptance test is one thing, but having to release every dependency because of minor version upgrade (which IMO is supposed to be compatible) is not a way to go either. If you don't favor ranges you could be explicit with compatible versions instead. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136383#4136383 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136383

18 years

1
0
0 / 0

[Design of POJO Server] - State of the integration of the latest MC into AS

by adrian＠jboss.org

I've got jboss-head (not with the latest maven stuff) booting with the latest MC code. The changes fall into the following categories (ignoring changes to build.xml/.classpath) * Updates to use the classloading spi * ClassLoaderFactory now uses DeploymentUnit rather than DeploymentContext * ControllerMode is now an Enum rather than an interface with constants * Removal of some hacks (and a temporary introduction of another - see below ;-) * Removal of generics on MetaType/Value in the profile service Here's the artifacts affected in case you are working on one of these areas: | [ejort@warjort jboss-head]$ svn status | M system-jmx/.classpathM system-jmx/src/tests/org/jboss/test/system/deployers/support/CLDeployer.java | M system-jmx/src/main/org/jboss/system/metadata/ServiceMetaDataParser.java | M system-jmx/src/main/org/jboss/system/server/jmx/JMXKernel.java | M system-jmx/src/main/org/jboss/system/deployers/ServiceClassLoaderDeployer.java | M system-jmx/src/main/org/jboss/system/deployers/HackClassloaderMetaDataDeployer.java | M system-jmx/src/main/org/jboss/system/microcontainer/jmx/ServiceControllerLifecycleCallback.java | M system-jmx/build.xml | M deployment/build.xml | M profileservice/src/main/org/jboss/profileservice/management/ManagementViewImpl.java | M profileservice/src/main/org/jboss/managed/plugins/factory/AbstractInstanceClassFactory.java | M profileservice/build.xml | M cluster/src/main/org/jboss/ha/jmx/HAServiceMBeanSupport.java | M ejb3/build.xml | M system/.classpath | M system/src/main/org/jboss/aop/deployers/temp/Hack.java | M system/src/main/org/jboss/system/server/profileservice/ProfileServiceBootstrap.java | M system/build.xml | M tomcat/src/main/org/jboss/web/tomcat/service/deployers/WarClassLoaderDeployer.java | M spring-int/src/main/org/jboss/spring/deployers/SpringParserDeployer.java | M spring-int/build.xml | M varia/src/main/org/jboss/varia/deployment/LegacyBeanShellDeployer.java | M varia/src/main/org/jboss/varia/deployment/LegacyBeanShellScriptDeployer.java | M varia/build.xml | M j2se/.classpath | M server/src/etc/conf/default/bootstrap-beans.xml | M server/build.xml | M bootstrap/.classpath | M bootstrap/build.xml | M messaging/build.xml | M webservices/src/main/org/jboss/wsf/container/jboss50/DynamicEndpointDeploymentAspect.java | M webservices/build.xml | M main/src/main/org/jboss/system/server/ServerLoader.java | M embedded/src/main/java/org/jboss/embedded/ClassLoaderDeployer.java | M embedded/.classpath | M testsuite/src/main/org/jboss/test/deployers/seam/test/SeamVFSClassloadingTestCase.java | M testsuite/build.xml | M connector/build.xml | M build/build-distr.xml | M build/build-thirdparty.xml | M aspects/src/main/org/jboss/aop/asintegration/jboss5/VFSClassLoaderDomainRegistry.java | M aspects/src/main/org/jboss/aop/asintegration/jboss5/JBoss5ClassPoolFactory.java | M aspects/src/main/org/jboss/aop/asintegration/jboss5/VFSClassLoaderScopingPolicy.java | M aspects/src/main/org/jboss/aspects/security/SecurityDomain.java | The work still do is what I expected (although a bit more in some parts) WEB CLASSLOADER The way this is currently implemented is conflicting with the infrastructure I've put in place to do this properly. I can get the server to boot without the WARClassLoaderDeployer stuff but obviously there's no scoping of wars. I'm going to work on integration the new mechanism properly next (well after I've synched with the maven build :-) MODULARISATION OF BOOTSTRAP There's a number of issues here, I'll deal with this on a different thread later. For now I've gone with the strategy of removing all the hacks and moving some jars back into ServerLoader (i,.e. the opposite of modularisation :-). This required the introduction of one new hack (setting the correct parent classloader on the default domain), | // FIXME | ClassLoaderDomain defaultDomain = system.getDefaultDomain(); | defaultDomain.setParent(new ClassLoaderToLoaderAdapter(getClass().getClassLoader())); | mbeanServer.registerMBean(system, new ObjectName("jboss.classloader:service=ClassLoaderSystem")); | but I can live with that until I do the modularisation properly. AOP INTEGRATION The temporary reversal of modularisation, i.e. moving some aop jars into ServerLoader has resolved the @JMX issue for now. But the major issue is that I haven't tested the changes to make aop's as integration use the org.jboss.classloading.spi.dependency classes rather than the old private classes from the deployers. OTHERS There's a couple of other minor issues I'm aware of, but these can be easily fixed. * @JMX is not registering the mbean with the correct classloader so invocations on the MBean use the wrong thread context classloader * The current way I am doing package scanning is not ignoring subdeployment roots correctly, e.g. /root.ear /root.ear/sub.jar /root.ear/sub.jar/com/acme/MyClass.class will create a package called com.acme as expected but also one called sub.jar.com.acme ;-) TIDY UP There's a fair amount of tidyup work to do as well but the modularisation work is probably when I'll do this. NEXT STEPS 1) Make this work with the new maven build 2) Replace the WarClassLoaderDeployer with the new subdeployment classloader mechanism 3) Make sure AOP is still working 4) Standup tests and fix problems (like the OTHERS raised above) 5) Commit it (with fair warning first :-) 6) Do the modularisation work (to be discussed) 7) Work towards getting proper RC1/GA releases of the MC artifacts e.g. fixing/refactoring the deployers and closing all the JIRA issues in the MC View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136382#4136382 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136382

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