November 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - AbstractClassLoaderDeployer changes

by scott.stark＠jboss.org

AbstractClassLoaderDeployer has been updated to first look for an attachment of type ClassLoaderFactory and it will use that factory rather than itself. Trying to introduce multiple class loading deployers was resulting in unnecessary class loaders being created. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985301#3985301 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985301

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Injection of MBeanServer

by bstansberry＠jboss.com

There are still issues with registering a beans.xml pojo in JMX with the @JMX annotation. See [url]http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985286#3985286 [/url]. This is holding me up from converting cluster-service.xml to a cluster-beans.xml. I need to get a working cache for the cluster-x.xml services or I can't even minimally test the various AS code conversions to the 2.0 API. To get around this, I'm going to go ahead and implement http://jira.jboss.com/jira/browse/JBCACHE-832, which will allow me to create a 2.0 cache service in the AS using a -service.xml file. Then I'll leave HAPartition et al in a cluster-service.xml until the @JMX issues are resolved. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985290#3985290 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985290

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: @JMX aspect and aop/mc integration

by bstansberry＠jboss.com

For any bean that calls any method in its constructor, if I add the @JMX annotation I'm getting an NPE during deployment. Typical stack trace follows: | 2006-11-12 17:02:10,062 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Instantiated: name=UnifiedInvokerHA state=Described | java.lang.RuntimeException: java.lang.NullPointerException | at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.getProxy(GeneratedAOPProxyFactory.java:115) | at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.createAdvisedProxy(GeneratedAOPProxyFactory.java:75) | at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.createAdvisedProxy(GeneratedAOPProxyFactory.java:39) | at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:82) | at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:71) | at org.jboss.kernel.plugins.dependency.InstantiateAction.installAction(InstantiateAction.java:52) | at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:96) | at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) | at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:226) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709) | at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:429) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:538) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:472) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:274) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177) | at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:67) | at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42) | at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:53) | at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52) | at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:145) | at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:440) | at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:451) | at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:381) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:366) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:246) | at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89) | at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:401) | at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:340) | at org.jboss.Main.boot(Main.java:210) | at org.jboss.Main$1.run(Main.java:508) | at java.lang.Thread.run(Thread.java:595) | Caused by: java.lang.NullPointerException | at AOPContainerProxy$4.setSubSystem(AOPContainerProxy$4.java) | at org.jboss.invocation.unified.server.UnifiedInvokerHA.<init>(UnifiedInvokerHA.java:50) | at AOPContainerProxy$4.<init>(AOPContainerProxy$4.java) | at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) | at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) | at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) | at java.lang.reflect.Constructor.newInstance(Constructor.java:494) | at java.lang.Class.newInstance0(Class.java:350) | at java.lang.Class.newInstance(Class.java:303) | at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.instantiateAndConfigureProxy(GeneratedAOPProxyFactory.java:128) | at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.getProxy(GeneratedAOPProxyFactory.java:111) | ... 30 more UnifiedInvokerHA calls its setSubsystem() method in it's constructor. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985286#3985286 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985286

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: @JMX aspect and aop/mc integration

by bstansberry＠jboss.com

"kabir.khan(a)jboss.com" wrote : The AspectManagerService currently has an "exclude" property to set all classes starting with "org.jboss." to not be transformed/inspected, which works on the underlying AspectManager singleton. Tip for anyone trying to convert a JMX microkernel-based service to an MC bean w/ the @JMX annotation -- if you find your bean doesn't get registered in JMX it's probably because of the above exclusion. To get around this, you need to add your class or a containing package to the "include" list in the AspectManager bean, found in deployers/jboss-aop-jboss5.deployer/META-INF/aspect-deployer-beans.xml. To get the services currently in cluster-service.xml registered, I would need to add org.jboss.cache.jmx, org.jboss.cache.pojo.jmx, org.jboss.ha, org.jboss.invocation.jrmp.server.JRMPInvokerHA, org.jboss.invocation.pooled.server.PooledInvokerHA and org.jboss.invocation.unified.server.UnifiedInvokerHA to this list. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985285#3985285 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985285

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Current behavior of DeploymentUnit.getAttachment

by scott.stark＠jboss.org

For now I just added a helper class that provides the desired child to parent search logic: | package org.jboss.deployers.plugins.deployers.helpers; | | import org.jboss.deployers.spi.deployer.DeploymentUnit; | import org.jboss.deployers.spi.structure.DeploymentContext; | | /** | * Search a DeploymentUnit structure from child to parent for a matching | * attachment. | * | * @author Scott.Stark(a)jboss.org | * @version $Revision:$ | */ | public class AttachmentLocator | { | static public Object search(DeploymentUnit unit, String name) | { | ... | } | | static public <T> T search(DeploymentUnit unit, String name, Class<T> expectedType) | { | ... | } | | static public <T> T search(DeploymentUnit unit, Class<T> type) | { | ... | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985280#3985280 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985280

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Current behavior of DeploymentUnit.getAttachment

by scott.stark＠jboss.org

Currently the only types of deployments that look to their parents for attachments are components. Subdeployments in ears do not see the ear attachments because they are not component deployment types. At this point I don't see a reason to differentiate between components and subdeployments in terms of searching the deployment structure from child to parent for attachments. What was the reason for not allowing subdeployments to see parent attachments? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985277#3985277 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985277

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Added simpleName and relativePathName accessors to the deplo

by scott.stark＠jboss.org

A number of deployers are trying to extract simple name/paths from the deployments, so I added getSimpleName, getRelativePath accessors to the DeploymentUnit interface to make this available. | /** | * Get the simple vfs name of the deployment unit. This is the simple | * name of the virtual file . | * | * vfs path ------------------- simple name | * deploy/some.ear "some.ear" | * deploy/some.ear/x.ejb "x.ejb" | * deploy/some.ear/y.sar "y.sar" | * deploy/some.ear/y.sar/z.rar "z.rar" | * deploy/complexwithappxml.ear/module-mbean1.sar/submbean.sar submbean.sar | * @return the deployment unit simple path | */ | public String getSimpleName(); | | /** | * Get the path of this deployment relative to the top of the | * deployment based on the vfs paths. For example, an ear: | * | * vfs path ------------------- relative path | * deploy/some.ear "" | * deploy/some.ear/x.ejb "/x.ejb" | * deploy/some.ear/y.sar "/y.sar" | * deploy/some.ear/y.sar/z.rar "/y.sar/z.rar" | * deploy/complexwithappxml.ear/module-mbean1.sar/submbean.sar /module-mbean1.sar/submbean.sar | * | * @return the top-level deployment relative path | */ | public String getRelativePath(); | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985275#3985275 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985275

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBAS-3766, port the webservice deployer

by scott.stark＠jboss.org

Another issue I'm seeing with the current JAXWSDeployerJSE is that it is trying to use the deployment class loader before the class loading deployers have committed. The JAXWSDeployerJSE should be before the WarDeployer, not just after the JBossWebAppParsingDeployer as use of the deployment class loader requires the deployer to be after the CLASSLOADER_DEPLOYER. I created a JBoss5VDFDeployerOrdering page as a reference for how to choose the deployer relative order: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5VDFDeployerOrdering It has also hard-coded its order so it cannot be overriden at the deployer descriptor level (http://jira.jboss.com/jira/browse/JBWS-1358). We need to remove this so any ordering issues can be corrected outside of the code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985264#3985264 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985264

19 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Identity model

by julien＠jboss.com

Bolek, I spent a couple of hours on that prototype that we discussed recently. The prototype is be some kind of stateful facade in front of the 4 modules we have today in the identity2 package. The state life cycle being managed by one unique object (session). It's very similar to hibernate/JCR except that it target user/role etc.. The benefits are that it offers a stateful view over the 4 modules. As well as a life cycle for scoping the different updates. Of course the goal is not to reinvent the wheel, the main motivation is that the modules can address different persistent store (DB, LDAP), there are even several implementations possible of some of them (membership module). So we would have that architecture : XXXModules -------------- Stateful session I have come to the conclusion that : 1/ the different modules needs to offer simple stateless operations, which seems to be the case today with the 4 different modules we have. If I retrieve data from a module and then use the module to update state affecting that data, then the object I retrieved is stale and the client should either get an updated object or compensate the state change. For instance : | Set roles = membershipmodule.getRoles(user); | membershipmodule.addRole(user, admin); | | // Needs to be updated | roles = membershipmodule.getRoles(user); | 2/ on the decision about to develop or not further more that embryon, I am not sure we need it right now. I think that for now we should keep what we have and ensure that we keep the same mind with the existing modules. Probably that the main motivation for that is that most of our operations are read only operations at runtime, and only the UserPortlet and RolePortlet needs to update those, so if those portlets are coded correctly there should not be any issue. Of course we could still develop that later if we have a need for it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985260#3985260 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985260

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: static field replication in PojoCache

by bela＠jboss.com

"ben.wang(a)jboss.com" wrote : | | I introduced that field annotation (@Replicatable) becuase I reckon there may be a case I don't want to replicate 1) any of the POJO static variables at all (this is happening most often); or 2) all of my static variables, e.g., | | | | org.jboss.cache.pojo.annotation.PojoCacheable | | public class POJO | | { | | @org.jboss.cache.pojo.annotation.Replicatble | | public static int someStaticVar; | | | | public static int anotherStaticVar; // this one won't get replicated. | | ... | | } | | | | I think this is not intuitive: @PojoCacheable replicates *all* variables, so static vars should be included. You can exclude static vars using the transient keyword or @transient annotation. anonymous wrote : | anonymous wrote : #2 Of course we need to support another static variable ! Ideally we adhere to the Java semantics | | Sure, it will be supported. I meant in my originally post that we won't support a static variable of "aspectized" POJO type, e.g., | | | org.jboss.cache.pojo.annotation.PojoCacheable | | public class Foo | | { | | ... | | } | | | | org.jboss.cache.pojo.annotation.PojoCacheable | | public class POJO | | { | | @org.jboss.cache.pojo.annotation.Replicatble | | public static Foo someStaticVar; // we cant support that someStaticVar is of type Foo of which is PojoCacheable. | | ... | | } | | | | Reason? Well, static variable is usually initialized failry early in the program lifecycle. So support of another POJO type to be managed by the PojoCache can be troublesome. I imagine mostly the static type to be primitive. Or am I assuming too much? | Can we at least try before we give up ? :-) I don't (currently) see why static vars should only be of primitive types... So, okay, we can create those instances but only replicate them once we have been fully initialized. anonymous wrote : | anonymous wrote : #5 Why ? we can have N someStaticVars per *cluster*... | | Now I don't get you. If someStaticVars is replicated, then there can only be a someStaticVar per *cluster* (sure, different VM will have their own instances). I was proposing to allow inside each VM, only one PojoCache instance is allowed to have static variable replication. Elias' discussion is also focused on this area as well. | Why should only 1 PojoCache be allowed to have static var replication inside the same VM ? This sounds like an arbitrary restriction... anonymous wrote : | Finally, on the naming of @PojoCacheable instead of @Clustered or @Replicated. I have thought about that before. I think @Clustered or @Clusterable is not appropriate becuase we are talking about state replication only (i.e., no client side load balancing). | | As for @Replicated, it is possible. But the expectation will be different. E.g., a user should not expect that once the Pojo is annotated and instantiated, then thing will happen automatically. That is, we are not using the API-less model; we still need to have api to *attach* the POJO. So @Replicated tag is a bit overloaded, IMO. | Still much better than @PojoCacheable, which is horrible View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985215#3985215 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985215

19 years, 5 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 November 2006