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

[Design of POJO Server] - Re: Deployment through the ProfileService api

by scott.stark＠jboss.org

The base deploymentURL is the raw deployment content location (user supplied ear, war, sar, rar, etc.). It has not admin edits associated with it. See the current org.jboss.system.server.profileservice.VFSScanner for how the current basic ProfileImpl is feed the deployment contexts from the standard bootstrap, deployers and deploy directory contents. The Profile api is being refactored to tie together repository support so that there is a base deployment notion coming from the addProfileContent method: | package org.jboss.profileservice.spi; | | import java.io.IOException; | import java.util.Collection; | import java.util.Map; | import java.util.zip.ZipInputStream; | | import org.jboss.deployers.spi.structure.DeploymentContext; | | /** | * A profile represents a named collection of deployments on a server. | * | * @author Scott.Stark(a)jboss.org | * @version $Revision$ | */ | public interface Profile | { | /** The class of deployment */ | public enum DeploymentPhase { | /** A deployment loaded during the server bootstrap phase */ | BOOTSTRAP, | /** An mc/service deployment for a Deployer to be loaded after the BOOTSTRAP phase */ | DEPLOYER, | /** Any deployment content to be loaded after the DEPLOYER phase */ | APPLICATION | }; | | /** | * The x.y.z version of the profile | * | * @return the version if known, null if its unspecified. | */ | public String getVersion(); | | /** | * Add raw content (bootstrap, deployers, deployments, libraries, etc) to a | * profile. | * | * @param name - a logical name for the content added | * @param contentIS - a zip input stream of the content layout as it is | * to be added to the profile. | * @param phase - the phase of the deployment as it relates to when the | * deployment is loaded | * @throws IOException | */ | public void addProfileContent(String name, ZipInputStream contentIS, DeploymentPhase phase) | throws IOException; | | /** | * Add a deployment | * | * @param d the deployment | * @param phase - the phase of the deployment as it relates to when the | * deployment is loaded | */ | public void addDeployment(DeploymentContext d, DeploymentPhase phase) | throws Exception; | | /** | * Remove a deployment | * | * @param name the name | * @param phase - the phase of the deployment as it relates to when the | * deployment is loaded | */ | public void removeDeployment(String name, DeploymentPhase phase) | throws Exception; | | /** | * Get a named deployment. | * | * @param name - the deployment name | * @param phase - the phase of the deployment as it relates to when the | * deployment is loaded | * @return the named bootstrap | * @throws NoSuchDeploymentException - if there is no such bootstrap | */ | public DeploymentContext getDeployment(String name, DeploymentPhase phase) | throws NoSuchDeploymentException; | | /** | * Get the names of the deployments in the profile | * @return names of deployments | */ | public Collection<String> getDeploymentNames(); | | /** | * Get the names of the deployments for the given phase defined in this profile | * @param phase - the phase of the deployment as it relates to when the | * deployment is loaded | * @return names of deployments | */ | public Collection<String> getDeploymentNames(DeploymentPhase phase); | | /** | * Get all deployments for the given phase defined in this profile | * | * @param phase - the phase of the deployment as it relates to when the | * deployment is loaded | * @return the bootstrap instances in this profile. | */ | public Collection<DeploymentContext> getDeployments(DeploymentPhase phase); | | | /** | * Get all deployments defined in this profile | * | * @return the deployment instances in this profile. | */ | public Collection<DeploymentContext> getDeployments(); | | /** | * Get the config | * | * @return the config | */ | public Map<String, Object> getConfig(); | } | The DeploymentTemplate notion has been moved to the ManagedView since it depends on the ManagedObject/ManagedProperty notions. These have been updated to the new mc versions of the classes. I'm still working to finalize this by tieing together the Profile, ManagentView and repository notions with the aspects that map the admin edits to a ManagedProperty back to the profile repository in the form a DeploymentContext Attachment overrides to the base DeploymentContext Attachments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998075#3998075 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998075

19 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Deployment through the ProfileService api

by charles.crouch＠jboss.com

"scott.stark(a)jboss.org" wrote : | Correct. However, for the initial tests I expect that the base deployment exists, so the way to add a deployment to a profile is: | | | | URL deploymentURL = ... | | VFS vfs = VFS.getVFS(deploymentURL); | | VirtualFile deploymentVF = vfs.getRoot(); | | AbstractDeploymentContext context = new AbstractDeploymentContext(deploymentVF); | | ps.addDeployment(context); | | | I'm confused about this last point. 1) What do you mean a "base" deployment? What is the "base" deployment in the scenario of wanting to deploy a brand new datasource? 2) In the pseudo code, deploymentURL presumably refers to this "base" deployment. Where would one obtain the deploymentURL from in the first place? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998066#3998066 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998066

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: ejb3-head testsuite

by akostadinov

Sorry, I didn't checked. I'll see how is it now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998054#3998054 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998054

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: ejb3-head testsuite

by bstansberry＠jboss.com

It was committed before I posted. Latest jboss-head-jdk-matrix build report from cruisecontrol shows it. Perhaps hasn't made it to anonymous svn yet? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998048#3998048 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998048

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover refactoring

by ovidiu.feodorov＠jboss.com

"clebert.suconic(a)jboss.com" wrote : > (and not the other local queues, as it was the case so far) | | We had routers taking care of this, balancing between local queues and failedover queues. Did you change this policy? No. This comes in top of the message pull policy, that it still in effect (well, right now it isn't since we're using a NullMessagePullPolicy, but if we were using one, it would be in effect). These behaviors complement each other. And by thew way, this reminds me that we should also test the pull policy, currently we have 0 tests for it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998044#3998044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998044

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: ejb3-head testsuite

by akostadinov

could that be commited to svn? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998043#3998043 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998043

19 years, 3 months

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: Interface exception checking seems broken

by scott.stark＠jboss.org

The rmi spec(which is hardly a spec) should not be dictating the exception checking, as its the ejb specs which define what is needed. Allowing superclasses of RemoteException is obvisously going to collide with generic application exceptions. The ejb spec is pretty clear about remote methods must be identified by a RemoteException, with any number of application exceptions. The current throwsRemoteException(Method) method is a confusion of checks that are mixing local and remote interface semantics: | /** | * Checks if the method includes java.rmi.RemoteException or its | * subclass in its throws clause. | * | * See bug report #434739 and #607805 | */ | public boolean throwsRemoteException(Method method) | { | Class[] exception = method.getExceptionTypes(); | | for (int i = 0; i < exception.length; ++i) | { | // Fix for bug #607805: an IOException is OK for local interfaces | // Fix for bug #626430: java.lang.Exception is also OK | if (exception.equals(java.io.IOException.class) | || exception.equals(java.lang.Exception.class)) | { | continue; | } | // Not true see bug report #434739 | // if (java.rmi.RemoteException.class.isAssignableFrom(exception)) | // According to the RMI spec. a remote interface must throw an RemoteException | // or any of its super classes therefore the check must be done vice versa | | if (isAssignableFrom(exception, "java.rmi.RemoteException")) | { | return true; | } | } | | return false; | } | None of the methods in this interface should be valid: | public interface X extends EJBObject | { | void m0() throws IOException; | void m1() throws Exception; | void m2() throws Throwable; | } | They are all valid for a local interface. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998041#3998041 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998041

19 years, 3 months

1
0
0 / 0

[Design of the JBoss EJB Container] - Interface exception checking seems broken

by scott.stark＠jboss.org

"henke.eriksson" wrote : | We ran into some trouble today when we tried to deploy an EJB with a | Local interface on JBoss 4.0.4. The business interface had one method, | which looked something like this: | | Object doStuff(Command c) throws Throwable; | | At deploy-time the verifier complained that we had a method in a local | interface that threw a RemoteException violating section 7.11.7 of the | EJB spec. | | We did some digging and stumbled across the bug report JBAS-1463. The | fix for this "bug" basically disallows a method in a local interface | to declare that it throws a RemoteException or any of its | SUPERclasses. As the report mentions, the RMI spec says that a Remote | method must declare that it throws a RemoteException or one of it | superclasses. But as far as I know a remote method can still declare | that it throws a subclass of RemoteException, right? | | Right now the verifier assumes that a method that declares that it | throws Throwable is a remote method. And I can see in the code that | fixes to allow Exception and IOException has been applied. But I still | feel that this logic is a bit weird, or am I missing something? | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998040#3998040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998040

19 years, 3 months

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: Support of J2EE 5.0 in JBoss 5.x

by scott.stark＠jboss.org

When certification is complete. Q1-Q2 timeframe. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998038#3998038 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998038

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: ejb3-head testsuite

by bstansberry＠jboss.com

I found that the clustering tests would fail to start due to OOM. The start-jboss macro in testsuite/imports/server-config.xml only gives 64M to the AS by default, which is no longer enough to start the server. I expect other tests that use the AS are failing for the same reason. For the clustering tests, I found modifying the tests-clustering-startup target so start-jboss looked like the following let them run: <start-jboss conf="node0" host="${node0}" jvmargs="-Xmx128M"/> I've checked in build-test.xml with that applied to all the start-jboss calls. I don't know if that will resolve all issues, but it's something. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998032#3998032 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998032

19 years, 3 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 January 2007