[Design of POJO Server] - Re: Controlling deployments via a barrier bean
by bstansberry＠jboss.com
"adrian(a)jboss.org" wrote : I'm saying that's the wrong approach.
OK, thanks. I knew you'd said that, but since it was under discussion I figured if I had time I'd figured out what was meant. :-)
anonymous wrote : The definition and implementation of the sub-profile is an orthogonal issue to how and when it gets activated.
Yes, it's the concept of content that's available in a profile that isn't active yet that needs to be fleshed out. That's fundamentally why I want to replace the current scanning based approach; it mixes the two.
There would probably need to be some API change related to this, in order to allow mgmt tools to activate/inactivate sub-profiles. If we didn't want to allow external clients to do that, it could just be done via an spi that an activation policy would use.
AIUI, though, the detection of an @Singleton annotation or some other form of deployment-specific metadata is always done by a deployer; i.e. is not part of the profile service itself. (Waiting to be told I'm wrong ;) ) So you end up with a chicken and egg problem; you need to start deploying to find out a deployment is in an inactive sub-profile. That's fundamentally what drove me to the idea of using dependencies. I'd much prefer an approach where the deployers aren't even aware of content that isn't "activated".
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155701#4155701
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155701
17 years, 10 months
[Design of EJB 3.0] - Re: trunk Ejb3Deployment is incompatible with jbossas trunk
by alesj
This is the 'svn diff' that I have locally:
| Index: ejb3/src/main/org/jboss/ejb3/deployers/Ejb3JBoss5Deployment.java
| ===================================================================
| --- ejb3/src/main/org/jboss/ejb3/deployers/Ejb3JBoss5Deployment.java (revision 74099)
| +++ ejb3/src/main/org/jboss/ejb3/deployers/Ejb3JBoss5Deployment.java (working copy)
| @@ -22,27 +22,29 @@
| package org.jboss.ejb3.deployers;
|
| import java.util.Map;
| -
| import javax.management.MBeanServer;
| import javax.management.ObjectName;
| -import javax.management.MalformedObjectNameException;
| import javax.security.jacc.PolicyConfiguration;
|
| import org.jboss.beans.metadata.plugins.AbstractSupplyMetaData;
| import org.jboss.deployment.MappedReferenceMetaDataResolverDeployer;
| import org.jboss.deployment.dependency.ContainerDependencyMetaData;
| -import org.jboss.ejb3.*;
| +import org.jboss.ejb3.Container;
| +import org.jboss.ejb3.DependencyPolicy;
| +import org.jboss.ejb3.DeploymentScope;
| +import org.jboss.ejb3.DeploymentUnit;
| +import org.jboss.ejb3.EJBContainer;
| +import org.jboss.ejb3.Ejb3Deployment;
| +import org.jboss.ejb3.MCDependencyPolicy;
| import org.jboss.ejb3.javaee.JavaEEComponent;
| -import org.jboss.ejb3.javaee.JavaEEModule;
| -import org.jboss.ejb3.javaee.JavaEEApplication;
| import org.jboss.ejb3.kernel.JNDIKernelRegistryPlugin;
| -import org.jboss.ejb3.metadata.jpa.spec.PersistenceUnitsMetaData;
| import org.jboss.kernel.Kernel;
| import org.jboss.logging.Logger;
| import org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData;
| import org.jboss.metadata.ejb.jboss.JBossMetaData;
| import org.jboss.metadata.ejb.jboss.JBossSessionBeanMetaData;
| import org.jboss.metadata.ejb.jboss.jndipolicy.spi.EjbDeploymentSummary;
| +import org.jboss.metadata.jpa.spec.PersistenceMetaData;
|
| /**
| * JBoss 5.0 Microkernel specific implementation
| @@ -57,7 +59,7 @@
| private org.jboss.deployers.structure.spi.DeploymentUnit jbossUnit;
| private Map<String, ContainerDependencyMetaData> endpoints;
|
| - public Ejb3JBoss5Deployment(DeploymentUnit ejb3Unit, Kernel kernel, MBeanServer mbeanServer, org.jboss.deployers.structure.spi.DeploymentUnit jbossUnit, DeploymentScope deploymentScope, JBossMetaData metaData, PersistenceUnitsMetaData persistenceUnitsMetaData)
| + public Ejb3JBoss5Deployment(DeploymentUnit ejb3Unit, Kernel kernel, MBeanServer mbeanServer, org.jboss.deployers.structure.spi.DeploymentUnit jbossUnit, DeploymentScope deploymentScope, JBossMetaData metaData, PersistenceMetaData persistenceUnitsMetaData)
| {
| super(ejb3Unit, deploymentScope, metaData, persistenceUnitsMetaData);
| this.jbossUnit = jbossUnit;
| Index: ejb3/src/main/org/jboss/ejb3/deployers/PersistenceUnitParsingDeployer.java
| ===================================================================
| --- ejb3/src/main/org/jboss/ejb3/deployers/PersistenceUnitParsingDeployer.java (revision 74099)
| +++ ejb3/src/main/org/jboss/ejb3/deployers/PersistenceUnitParsingDeployer.java (working copy)
| @@ -21,21 +21,9 @@
| */
| package org.jboss.ejb3.deployers;
|
| -import java.net.URL;
| -import java.util.HashMap;
| +import org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer;
| +import org.jboss.metadata.jpa.spec.PersistenceMetaData;
|
| -import javax.persistence.spi.PersistenceUnitTransactionType;
| -
| -import org.hibernate.cfg.EJB3DTDEntityResolver;
| -import org.hibernate.ejb.packaging.PersistenceXmlLoader;
| -import org.jboss.deployers.structure.spi.DeploymentUnit;
| -import org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer;
| -import org.jboss.deployers.vfs.spi.structure.VFSDeploymentUnit;
| -import org.jboss.ejb3.metadata.jpa.spec.PersistenceUnitsMetaData;
| -import org.jboss.ejb3.protocol.jarjar.Handler;
| -import org.jboss.logging.Logger;
| -import org.jboss.virtual.VirtualFile;
| -
| /**
| * Find and parse persistence.xml.
| *
| @@ -46,74 +34,15 @@
| * WEB-INF/classes/META-INF/persistence.xml
| *
| * @author <a href="mailto:carlo.dewolf@jboss.com">Carlo de Wolf</a>
| + * @author <a href="mailto:ales.justin@jboss.com">Ales Justin</a>
| * @version $Revision$
| */
| -public class PersistenceUnitParsingDeployer extends AbstractVFSParsingDeployer<PersistenceUnitsMetaData>
| +public class PersistenceUnitParsingDeployer extends SchemaResolverDeployer<PersistenceMetaData>
| {
| - private static final Logger log = Logger.getLogger(PersistenceUnitParsingDeployer.class);
| -
| - static
| - {
| - Handler.init();
| - }
| -
| public PersistenceUnitParsingDeployer()
| {
| - super(PersistenceUnitsMetaData.class);
| + super(PersistenceMetaData.class);
| setName("persistence.xml");
| + setRegisterWithJBossXB(true);
| }
| -
| - @Override
| - protected PersistenceUnitsMetaData parse(DeploymentUnit unit, String name, PersistenceUnitsMetaData root) throws Exception
| - {
| - // Try to find the metadata
| - VFSDeploymentUnit vfsDeploymentUnit = (VFSDeploymentUnit) unit;
| -
| - VirtualFile file = vfsDeploymentUnit.getMetaDataFile(name);
| - if (file == null)
| - {
| - // FIXME: hack to get a war persistence unit
| - try
| - {
| - file = vfsDeploymentUnit.getFile("WEB-INF/classes/META-INF/persistence.xml");
| - if(file == null)
| - return null;
| - }
| - catch(IllegalStateException e)
| - {
| - return null;
| - }
| - // -- //
| - }
| -
| - PersistenceUnitsMetaData result = parse(vfsDeploymentUnit, file, root);
| - if (result != null)
| - init(vfsDeploymentUnit, result, file);
| - return result;
| - }
| -
| - @Override
| - protected PersistenceUnitsMetaData parse(VFSDeploymentUnit unit, VirtualFile file, PersistenceUnitsMetaData root)
| - throws Exception
| - {
| - VirtualFile persistenceRoot = file.getParent().getParent();
| -
| - // We can't pass in a VFS url.
| - //URL persistenceUnitRootUrl = persistenceRoot.toURL();
| -
| - // FIXME: is this a supported hack?
| - // This introduces severe regression, will go the jar: url way (EJB-326)
| - //URL persistenceUnitRootUrl = new URL("jarjar:" + persistenceRoot.getHandler().toURL());
| -
| - // http://opensource.atlassian.com/projects/hibernate/browse/EJB-326
| - URL persistenceUnitRootUrl = persistenceRoot.toURL();
| - assert persistenceUnitRootUrl.getProtocol().equals("jar") || persistenceUnitRootUrl.getProtocol().equals("file") : "expected a jar or file url, but was " + persistenceUnitRootUrl;
| -
| - URL persistenceXmlUrl = file.toURL();
| - PersistenceUnitsMetaData metaData = new PersistenceUnitsMetaData(persistenceUnitRootUrl, PersistenceXmlLoader.deploy(persistenceXmlUrl, new HashMap<String, String>(),
| - new EJB3DTDEntityResolver(), PersistenceUnitTransactionType.JTA));
| - log.info("Found persistence units " + metaData);
| - // FIXME: if in EAR then unscoped else scoped
| - return metaData;
| - }
| }
| Index: ejb3/src/main/org/jboss/ejb3/deployers/Ejb3Deployer.java
| ===================================================================
| --- ejb3/src/main/org/jboss/ejb3/deployers/Ejb3Deployer.java (revision 74099)
| +++ ejb3/src/main/org/jboss/ejb3/deployers/Ejb3Deployer.java (working copy)
| @@ -23,7 +23,6 @@
|
| import java.util.Properties;
| import java.util.Set;
| -
| import javax.management.MBeanServer;
|
| import org.jboss.deployers.spi.DeploymentException;
| @@ -41,8 +40,8 @@
| import org.jboss.ejb3.proxy.factory.RemoteProxyFactoryRegistry;
| import org.jboss.kernel.Kernel;
| import org.jboss.kernel.spi.deployment.KernelDeployment;
| -import org.jboss.metadata.ear.jboss.JBossAppMetaData;
| import org.jboss.metadata.ejb.jboss.JBossMetaData;
| +import org.jboss.metadata.jpa.spec.PersistenceMetaData;
| import org.jboss.metadata.web.jboss.JBossWebMetaData;
| import org.jboss.virtual.VirtualFile;
|
| @@ -92,10 +91,10 @@
| @Override
| public void deploy(VFSDeploymentUnit unit) throws DeploymentException
| {
| - deploy(unit, unit.getAttachment(JBossMetaData.class), unit.getAttachment(PersistenceUnitsMetaData.class));
| + deploy(unit, unit.getAttachment(JBossMetaData.class), unit.getAttachment(PersistenceMetaData.class));
| }
|
| - public void deploy(VFSDeploymentUnit unit, JBossMetaData metaData, PersistenceUnitsMetaData persistenceUnitsMetaData) throws DeploymentException
| + public void deploy(VFSDeploymentUnit unit, JBossMetaData metaData, PersistenceMetaData persistenceUnitsMetaData) throws DeploymentException
| {
| try
| {
|
Which fixes this.
btw: I've commited the change + released VFS 2.0.0.Beta13.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155681#4155681
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155681
17 years, 10 months
[Design of POJO Server] - Re: JBAS-5578 ServiceMBeanSupport as MC bean
by alesj
"adrian(a)jboss.org" wrote :
|
| | // Implement this interface so we know the true name not the JMX wrapper
| | // when we are registered as a POJO
| | KernelControllerContextAware
| |
|
btw: this breaks the AS5_trunk ;-)
Just did a clean 'svn update, build clean most':
| _default:compile-classes:
| [mkdir] Created dir: C:\projects\jboss5\trunk\jbossmq\output\gen-src
| [javac] Compiling 200 source files to C:\projects\jboss5\trunk\jbossmq\output\classes
| C:\projects\jboss5\trunk\jbossmq\src\main\org\jboss\mq\il\ServerILJMXService.java:48: cannot access org.jboss.kernel.spi.dependency.KernelControllerContextAware
| file org\jboss\kernel\spi\dependency\KernelControllerContextAware.class not found
| public abstract class ServerILJMXService extends ServiceMBeanSupport implements ServerILJMXServiceMBean
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155669#4155669
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155669
17 years, 10 months
[Design of POJO Server] - Re: JBAS-5578 ServiceMBeanSupport as MC bean
by adrian＠jboss.org
Never mind, I think I figured out what the problem is.
The issue occurs when you register a ServiceMBeanSupport MBean using registerDirect=true on the JMX annotation.
The callstack then goes something like:
MC - > ServiceMBeanSupport.create() -> ServiceController.create()
ServiceController.create() then ignores the request because it thinks it is a call
on the JMX lifecycle, i.e. a duplicate
I fixed this problem by introducing POJO lifecycle events in ServiceMBeanSupport
so we can differentiate the two.
| @Create
| public void pojoCreate() throws Exception
| {
| jbossInternalCreate();
| }
|
This brings up to other issues. The first of which I fixed which is related
to the confusion when JMX and POJO lifecycles.
If you invoke a lifecycle operation on the JMX console (or any MBeanServer operation)
then it should be redirected to the MC for a POJO not the ServiceController.
The JMX part is just a wrapper.
Since we now have the seperate pojoXXX methods, this is easy to spot,
so ServiceMBeanSupport now does the redirection, e.g.
| public class ServiceMBeanSupport
| extends JBossNotificationBroadcasterSupport
| implements ServiceMBean, MBeanRegistration,
|
| // Implement this interface so we know the true name not the JMX wrapper
| // when we are registered as a POJO
| KernelControllerContextAware
|
| public void setKernelControllerContext(KernelControllerContext controllerContext) throws Exception
| {
| this.controllerContext = controllerContext;
| }
|
| public void unsetKernelControllerContext(KernelControllerContext controllerContext) throws Exception
| {
| this.controllerContext = null;
| }
|
| // Redirect JMX invocations to the real MC context, e.g.
|
| public void create() throws Exception
| {
| if (controllerContext != null)
| pojoChange(ControllerState.CREATE);
| else if (serviceName != null && isJBossInternalLifecycleExposed)
| server.invoke(ServiceController.OBJECT_NAME, "create", new Object[] { serviceName }, SERVICE_CONTROLLER_SIG);
| else
| jbossInternalCreate();
| }
|
The second issue is the use of StandardMBean in the @JMX handling.
The problem is that this masks any implemention of MBeanRegistration
or NotificationEmitter.
This is probably not a real issue since you can always use
registerDirectly=true on the @JMX annotation
to expose those contracts.
You're pretty certain its going to be a real mbean if you implements them.
A more general fix would to use of an extension of StandardMBean
that delegates those interface implementations to underlying pojo
if it implements them.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155661#4155661
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155661
17 years, 10 months