[Design of OSGi Integration] - Re: Facade Questions
by johnbailey
Assuming the DeploymentControllerContext is always available to the Bundle, can we also assume the DeploymentControllerContext has also been installed into the Controller? Looking through the DeployersImpl the DeploymentControllerContext is created, installed into the controller, attached to the DeploymentContext, and moved through all known states for the DeployersImpl.
So if the Bundle.start method delegates to the DeploymentControllerContext.changeState(...), would it look something like this:
| public void start() throws BundleException
| {
| DeploymentControllerContext deploymentControllerContext = getControllerContext();
| DeploymentContext deploymentContext = deploymentControllerContext.getDeploymentContext();
|
| // Go through the states in order
| List<ControllerState> states = getControllerContext().getController().getStates();
| for (ControllerState state : states)
| {
| if (DeploymentState.ERROR.equals(deploymentContext.getState()) == false)
| {
| try
| {
| deploymentControllerContext.getController().change(getControllerContext(), state);
| }
| catch (Throwable t)
| {
| deploymentContext.setState(DeploymentState.ERROR);
| deploymentContext.setProblem(t);
| }
| }
| }
|
| }
|
Also, I have completed some other work on the Facade, should I document it on the existing 'OSGI Facade' JIRA http://jira.jboss.com/jira/browse/JBOSGI-8, or create a more detailed task?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131726#4131726
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131726
18 years, 1 month
[QA of JBoss Portal] - Update to poms
by julien@jboss.com
I am trying to trim down a bit the pom dependencies we are using to keep only what is necessary.
For instance the web module poms declares lot of stuff it does not have to declares:
- jbossxb : is not used directly and is already declared by its consumers (microcontainer)
- jboss vfs : same
- javassist : same
However those jars are needed to build test cases, but maven antrun extended plugin is able to resolve the dependencies transitively so it works.
The only dependency I am not able to remove is the concurrent oswego jar. For some reason it is used by something but I cannot determine what. I have removed first the dependency of the common module over that concurrent jar (by using java.util.concurrent)...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131691#4131691
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131691
18 years, 1 month
[Design of JBoss Build System] - Re: JBossAS CR1 build plan
by scott.stark@jboss.org
So based on this morning's call there are two possible plans:
a. Paul works on reproducing the current local jbossas trunk thirdparty structure from maven artifacts. This requires that the existing jbossas project artifacts are the same as the current jbossbuild artifacts. The steps to build and test the server would be:
a1. Build the jbossas projects that ejb3 depends on using maven to make them available via the maven repo.
a2. Build ejb3 to make its artifacts available via the maven repo.
a3. Build the remaining jbossas projects using maven to make them available via the maven repo.
a4. Run an assembly step equivalent to the current build-thirdparty.xml to produce a local thirdparty repository from the maven repository rather than the jbossbuild repository. This allows the existing build/build-distr.xml, testsuite and eclipse project/classpath settings, config files, etc. to remain unchanged.
a5. Run the build/build-distr.xml to create the jboss-5.0.0.CR1 distribution structure.
a6. Run the testsuite as ususal to validate the artifacts. Note that this either requires that the target directory for the maven builds use the jbossbuild output/lib convention, or the testsuite module classpaths need to be updated to refer to the target/* locations of the maven build.
The B plan would be to simply:
b1. Build the jbossas projects that ejb3 depends on using maven to make them available via the maven repo.
b2. Build ejb3 to make its artifacts available via the maven repo.
b3. Upload the ejb3 artifacts to the jbossbuild repository
b4. Run the jbossbuild as ususual.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131570#4131570
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131570
18 years, 1 month