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

[Design of POJO Server] - Re: Deploying Ears and Wars through ProfileService

by scott.stark＠jboss.org

"mark.spritzler" wrote : Is there an api yet to discovery the ears and wars already deployed? | | The KnownComponentTypes doesn't define an ear or war type to use to query the ManagementView. | | Mark It does not exist yet, and could be part of the JBAS-5529 issue, but it should be implemented using the ManagementView.getDeploymentNamesForType method: | /** | * Get the names of the deployment in the profile that have the | * given deployment type. | * @param type - the deployment type | * @return the names | */ | public Set<String> getDeploymentNamesForType(String type); | The issue is that the ear/war/ejb-jar/client-jar deployment classifications are not component types that correspond to runtime components with a ManagedComponent. They are classifications of ManagedDeployments. So I think what we really need is a KnownDeploymentTypes enum with the standard jbossas deployment types listed. I have added another subtask for this: http://jira.jboss.com/jira/browse/JBAS-5557 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153967#4153967 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153967

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Deploying Ears and Wars through ProfileService

by scott.stark＠jboss.org

"mark.spritzler" wrote : So, all that code is just for mcbean deployments, whereas ear deployments only need the distribute method. | No, every deployment type will need the 3 steps: DISTRIBUTE, DESCRIBE, START. If you don't care to validate the dependencies we should allow START alone. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153959#4153959 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153959

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Deploying Ears and Wars through ProfileService

by scott.stark＠jboss.org

"mark.spritzler" wrote : | So, a listener to get callbacks on the lifecycle of the deploying? What does that interface look like, actually I can just look it up. | | But the run() goes how far, in the case of a war file? | The listener interface just receives ProgressEvents: | public interface ProgressListener | { | void progressEvent(ProgressEvent eventInfo); | } | which is a DeployentID(identifies the deployment) and a DeploymentStatus which provides what target, command, status of command being performed is. There is no difference in the distribute behavior for an mcbeans deployment vs an ear/war. I will be introducing a describe/prepare command as discussed with Brian as part of the farming support in this thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151467 "mark.spritzler" wrote : | | | DeploymentStatus status = progress.getDeploymentStatus(); | | assertTrue("DeploymentStatus.isCompleted", status.isCompleted()); | | // It should not be running yet | | assertFalse("DeploymentStatus.isRunning", status.isRunning()); | | assertFalse("DeploymentStatus.isFailed", status.isFailed()); | | | | This confused me just a tad, if only the file has been "copied" but hasn't been fully deployed and started, how is it completed==true. Unless the definition of completed is just that the file has been fully "copied" | completed==true indicates the completion of the command being run. Right now there are the following commands: | package org.jboss.deployers.spi.management.deploy; | public interface DeploymentStatus | { | public enum StateType { | UPLOADING, DEPLOYING, RUNNING, COMPLETED, FAILED, CANCELLED | } | public enum CommandType { | DISTRIBUTE, // Copies the raw deployment contents to a profile repository | START, // Runs the deployment through the full MC deployment states all the way to INSTALLED | STOP, // Uninstalls the deployment from the MC but leaves the deployment in the profile repository | UNDEPLOY, // Removes the deployment from the profile repository | REDEPLOY // Uninstalls the deployment, updates the profile repository and installs the deployment. | } | and a DESCRIBE/PREPARE command will be added. It will validate that the deployment can be successfully configured to the MC DESCRIBED state which is where all dependencies have been resolved. "mark.spritzler" wrote : | | | // Now start the deployment | | progress = mgtView.start("testMCBeansDeployment.beans", DeploymentPhase.APPLICATION); | | progress.addProgressListener(this); | | progress.run(); | | status = progress.getDeploymentStatus(); | | assertTrue("DeploymentStatus.isCompleted", status.isCompleted()); | | assertTrue("DeploymentStatus.isRunning", status.isRunning()); | | assertFalse("DeploymentStatus.isFailed", status.isFailed()); | | | | OK, so by looking at this code, it just looks like all the steps of "deploying" a war are all covered so that any management console can keep track of the entire process, instead of a "one swooping step to follow" from a management perspective. | | Overall, We are pretty flexible in "mapping" the process to fit into the JON plugin notion. So I don't forsee any issue with how you set this up, as usual it is pretty clean and easy to understand. | So the earlier jbossas notions of a single deploy process that included copying/making the deployment available and running are broken up into 3 command steps now: 1. DISTRIBUTE - make the deployment contents available to the profile repository(ies). There may be multiple if clustered. You should comment on the farming thread with regard to what clustering exists at the JON level and how that might conflict/use any native profile service cluster notions. 2. DESCRIBE - validate that the deployment can be run through the deploy process to the MC DESCRIBED state to validate that all references/dependencies can be satisfied. Failure here should return a detailed description of what dependencies are missing. 3. START - complete the deployment processing to bring the deployment components to the MC INSTALLED state. There is no guarantee one can successfully go from DESCRIBED to INSTALLED, so failure to start also needs to provide detailed info on the problems. Charles and I talked about that having invalid deployments as part of the unit test would be needed to make sure the problems are adequately reported to the admin tool layer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153958#4153958 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153958

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS and directory handling

by scott.stark＠jboss.org

This is the same situation that exists without the vfs for exploded vs packed jars. The only difference without the vfs is that the url prefix is probably jar: for packed, file: for exploded. There is no generic solution I can see, but this interaction between ejb3 and hibernate is part of the javax.persistence.spi.PersistenceUnitInfo where there is a contract defined to either return a file: url, or an InputStream to the jar. Its the PersistenceUnitInfo implementation that needs to be vfs aware, not hibernate. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153947#4153947 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153947

18 years

1
0
0 / 0

[Design of EJB 3.0] - Re: Feature: MC Equivalent of @Service

by wolfc

You need to differentiate between EJB 3 and POJO Server. POJO Server provides Tx, Security for any MC Bean. The only difference is the detached instances. It's a misconception that a service bean requires a management interface. It's also a misconception that that management interface actually manages the container life cycle. It's a very basic chicken/egg problem. If I stop either chicken or egg, there will be no more eggs to start. (See also http://jira.jboss.org/jira/browse/EJBTHREE-655) What is easily possible is a MC view on an EJB. This should not require any new container and should be applicable to both SLSB and Service/Singleton. As for the actual life cycle callbacks, these are @PostConstruct and @PreDestroy. Although create, start, stop and destroy will probably also be called by MC (in about the same way we now call the @Management interface). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153942#4153942 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153942

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Getting aop 2.0.0.CR10 jars into AS

by kabir.khan＠jboss.com

It fails if I just specify the plugin | kabir(a)~/sourcecontrol/thirdparty/legacy/jboss/aop/2.0.0.CR10] | $mvn org.jboss.maven.plugins:maven-buildmagic-thirdparty-plugin:maven-deploy -Durl=file:///Users/kabir/sourcecontrol/thirdparty/maven2/ | [INFO] Scanning for projects... | [INFO] ------------------------------------------------------------------------ | [ERROR] BUILD ERROR | [INFO] ------------------------------------------------------------------------ | [INFO] The plugin 'org.jboss.maven.plugins:maven-buildmagic-thirdparty-plugin' does not exist or no valid version could be found | [INFO] ------------------------------------------------------------------------ | [INFO] For more information, run Maven with the -e switch | [INFO] ------------------------------------------------------------------------ | [INFO] Total time: < 1 second | [INFO] Finished at: Wed May 28 13:12:27 BST 2008 | [INFO] Final Memory: 1M/2M | [INFO] ------------------------------------------------------------------------ | but works if I specify the version number for the plugin | [kabir(a)~/sourcecontrol/thirdparty/legacy/jboss/aop/2.0.0.CR10] | $mvn org.jboss.maven.plugins:maven-buildmagic-thirdparty-plugin:2.0:maven-deploy -Durl=file:///Users/kabir/sourcecontrol/thirdparty/maven2/ | ... | [INFO] BUILD SUCCESSFUL | [INFO] ------------------------------------------------------------------------ | [INFO] Total time: 2 seconds | [INFO] Finished at: Wed May 28 13:12:39 BST 2008 | [INFO] Final Memory: 2M/4M | [INFO] ------------------------------------------------------------------------ | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153922#4153922 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153922

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Getting aop 2.0.0.CR10 jars into AS

by kabir.khan＠jboss.com

With Paul's help, we found that if the plugin is not downloaded yet, and mvn is run from a directory with no pom.xml, it ignores any repositories specified in settings.xml! Once the plugin is downloaded it should be possible to run it from anywhere. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153918#4153918 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153918

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Facelets scanning for .taglib.xml is broken in trunk

by alesj

"alesj" wrote : | Any ideas on how to handle this still in no-VFS-aware way? | I should give up on the forum more often. :-) An instance after I posted this I had 2 hack ideas. OK, I hacked this one, and it works. :-) | private static void searchFromURL(Set result, String prefix, String suffix, URL url) throws IOException | { | boolean done = false; | InputStream is = getInputStream(url); | if (is != null) | { | try | { | ZipInputStream zis; | if (is instanceof ZipInputStream) | zis = (ZipInputStream)is; | else | zis = new ZipInputStream(is); | ZipEntry entry = zis.getNextEntry(); | String urlString = url.toExternalForm(); | while (entry != null) | { | String entryName = entry.getName(); | if (entryName.endsWith(suffix)) | { | result.add(new URL(urlString + entryName)); | } | entry = zis.getNextEntry(); | } | done = true; | } | catch (Exception ignore) | { | } | } | if (done == false && prefix.length() > 0) | { | String urlString = url.toExternalForm(); | String[] split = prefix.split("/"); | prefix = join(split, false); | String end = join(split, true); | int p = urlString.lastIndexOf(end); | url = new URL(urlString.substring(0, p)); | searchFromURL(result, prefix, suffix, url); | } | } | | private static String join(String[] split, boolean full) | { | String join = ""; | for (int j =0; j < split.length - (full ? 0 : 1); j++) | join += split[j]; | return join; | } | | private static InputStream getInputStream(URL url) | { | try | { | return url.openStream(); | } | catch (Throwable t) | { | return null; | } | } | Good enough? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153915#4153915 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153915

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Facelets scanning for .taglib.xml is broken in trunk

by alesj

"scott.stark(a)jboss.org" wrote : If JarFile supported a JarInputStream I would look at support a JarURLConnection from the handler, but you have to have a path to a file as far as I can see. | | I would say hacking the facelets code to create patch Classpath to try to use a JarInputStream to find the taglib descriptiors is the best approach. There will be a patched facelets jars required, and we give back the patch. | I've hacked this sandbox env: - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/dep... For the packed.jar case I don't see how are we gonna do that. Since our BaseClassLoader.getResource("META-INF/") returns URL that points to VFS's SynthenticDirEntryHandler. And this one currently doesn't know to do much: | public InputStream openStream() throws IOException | { | throw new IOException("Directories cannot be opened"); | } | Any ideas on how to handle this still in no-VFS-aware way? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153903#4153903 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153903

18 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Mina client/server session id's

by ataylor

anonymous wrote : I don't think the session id should be exposed in the remoting session listener anyway- this is an implementation detail that is of no use to the user. Ive left this in for now since the connection manager is reliant on it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153895#4153895 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153895

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 May 2008