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

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by bstansberry＠jboss.com

"scott.stark(a)jboss.org" wrote : "emuckenhuber" wrote : | | Because i think in the end there will be quite a lot of immutable profiles (defined over xml), where you basically | | don't have hot-deployment scanning. | | And just the deploy/ directory and the clustering directories as hot-deployment profiles. | | IMHO as soon, as you define deployments in a profile, it does not make sense to search for new content. | | | | I'm not sure what your getting at with the last statement. We certainly will have hot deployment, and so a dynamic profile is needed. I would think that the distinction between dynamic/static should be explicit and the current code in the HDScanner that obtains the active profiles would get the dynamic profiles Are two different concepts getting mixed here? 1) Statically defined vs. dynamic profiles. In the former all the contents of the profile are explicitly listed, in the latter a (set of) root URLs is defined and whatever is under those roots becomes part of the profile. The former is largely used to define the server's JBoss-provided capabilities, the latter provides the "drop a war in deploy/ and it gets deployed" functionality for users. 2) Hot deployment == we monitor the profile's contents and if a file changes we redeploy. This applies to both static and dynamic profiles. For dynamic profiles this also includes detecting new items under the root URL and the removal of items under the root URL. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205990#4205990 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205990

16 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by scott.stark＠jboss.org

"emuckenhuber" wrote : | I think it would be enough to have that in the ManagementView only. | The ManagementView was the only user of the call, so if you have folded the impl into its impl there is no reason to have if on the Profile. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205982#4205982 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205982

16 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by scott.stark＠jboss.org

"emuckenhuber" wrote : | Therefore we could have one HDScanner thread per profile and DeploymentManager suspends the scanner, | when it's uploading contents. | | Because i think in the end there will be quite a lot of immutable profiles (defined over xml), where you basically | don't have hot-deployment scanning. | And just the deploy/ directory and the clustering directories as hot-deployment profiles. | IMHO as soon, as you define deployments in a profile, it does not make sense to search for new content. | I'm not sure what your getting at with the last statement. We certainly will have hot deployment, and so a dynamic profile is needed. I would think that the distinction between dynamic/static should be explicit and the current code in the HDScanner that obtains the active profiles would get the dynamic profiles: | // Get the active profiles | Collection<ProfileKey> dynamicProfiles = profileService.getDynamicProfileKeys(); | if(activeProfiles == null || activeProfiles.isEmpty()) | { | if( trace ) | log.trace("End deployment scan, no dynamic profiles"); | return; | } | I would say the DeploymentManager disabled dynamic profile access using the ProfileService rather than knowing about an HDScanner. However, the problem is that in general a scan will have started just before the DeploymentManager has disabled the dynamic profile access, so either the new upload has to wait for the current scan to complete (which there currently is no good way to do), or the upload has to deal with concurrency. Actually, since the upload needs to be targeted to a profile, if only dynamic profiles support adding content, one can know if there is an active query for the modified deployments and block the upload until its done. Let's sketch out all of the usecases of N dynamic profiles, any of which can be updated via direct access and the DeploymentManager to come up with a stable solution and base the spi from that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205981#4205981 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205981

16 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by emuckenhuber

To hijack my own thread there is actually one remaining thing in the Profile spi, which i think is not really required: | public interface Profile | { | /** | * Update a deployment. This can be used to save attachments, other | * metadata of the deployment. | */ | void updateDeployment(VFSDeployment d, ManagedComponent comp) throws Exception; | | } | I think it would be enough to have that in the ManagementView only. A short explanation why... i've worked on removing the VFSDeployment from the profileservice-spi, which seems to work pretty well. But the main thing which changed is that ProfileService does not directly use the MainDeployer anymore, but a kind of wrapper which actually creates a Deployment or VFSDeployment, restores the attachments and then adds the deployment to the MainDeployer Therefore ManagementView could simply take care of that, so that we don't have the attachment persistence in 2 different places. What do you think? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205976#4205976 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205976

16 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by emuckenhuber

"scott.stark(a)jboss.org" wrote : | The locking and enableModifiedDeploymentChecks were hacks to get the hot deployment scanning from interfering with copying new deployment content. The repository itself could either have this flag if its still needed, or just put the burden on the repository implementation to handle concurrency better. The externalized locking and enableModifiedDeploymentChecks were hacks to avoid concurrency problems I was seeing, so first consider just removing them. | Okay good to know - that's why i was thinking that DeploymentManager should suspends the profile automatically from scanning. As we might allow a profile definition like this (at one point): | <hotdeployment-profile name="myhotdeploymentProfile"> | <profile source .../> | <scan-period>12345</scan-period> | </hotdeployment-profile> | Therefore we could have one HDScanner thread per profile and DeploymentManager suspends the scanner, when it's uploading contents. Because i think in the end there will be quite a lot of immutable profiles (defined over xml), where you basically don't have hot-deployment scanning. And just the deploy/ directory and the clustering directories as hot-deployment profiles. IMHO as soon, as you define deployments in a profile, it does not make sense to search for new content. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205975#4205975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205975

16 years, 1 month

1
0
0 / 0

[Design of JBoss Identity] - Re: List of Users

by bdaw

I think the main confusion is a bit about naming: IdentityType - parent interface for Identity and Group Identity aka user Group aka group... This is covered in the "API" part of the design doc: http://www.jboss.org/community/docs/DOC-13261 The decision to use the name "Identity" and not simply "User" was mainly because "Identity" in some authentication/authorization scenarios can be also machines... Now I'm a bit afraid that it will confuse people. So for the methods: | identitySession.getPersistenceManager() | .findIdentity(null); | will return all Identity objects (so all users if you prefer such naming) | identitySession.getPersistenceManager(). | findGroup(groupType, null) all Group objects for a given group type. Then controls only let to narrow or order/sort results. With RelationshipManager you can get all Group objects associated with a given Identity regardless of the GroupType. To follow some "real life" scenario with the API look at this API test case: http://anonsvn.jboss.org/repos/jbossidentity/idm/trunk/idm/src/test/java/... One of the tests map small part of the structure of jboss.org projects so should let to understand API concepts better. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205974#4205974 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205974

16 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by scott.stark＠jboss.org

"emuckenhuber" wrote : Last but not least - the deploymentManager is one of the remaining parts which are making the cleanup of the profileservice-spi a bit harder. | | Especially the basic locking which is done when copying a file into a hot-deployment folder. | So maybe we want to remove the enableModifiedDeploymentChecks from the Profile spi: | The locking and enableModifiedDeploymentChecks were hacks to get the hot deployment scanning from interfering with copying new deployment content. The repository itself could either have this flag if its still needed, or just put the burden on the repository implementation to handle concurrency better. The externalized locking and enableModifiedDeploymentChecks were hacks to avoid concurrency problems I was seeing, so first consider just removing them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205969#4205969 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205969

16 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by scott.stark＠jboss.org

"emuckenhuber" wrote : There is also the question whether DeploymentManager.loadProfile(ProfileKey key) is still valid | when having more active profiles. | Isn't it still loadProfile(ProfileKey key, boolean allowHotDeployments)? Its just a question of which profile the deployment is being added to. Calling profile.enableModifiedDeploymentChecks(allowHotDeployments) and obtaining the DeploymentRepository to upload the content are the two things this does. The later still needs to be done in my view. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205966#4205966 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205966

16 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: BPMN in jbpm4

by kukeltje

1) Creative.... and I think it can be defended if is is just explained in enough detail in the docs. 2) First of all, I did not use superstates once (did not have the real need), secondly and IANAE, BPMN has the notion of embedded and reusable subprocesses (the latter are renamed to call activity if I am informed correctly). Though there is no relation between the type and the way they should be displayed, I think that can be leveraged: - collapsed can be either subprocess or superstate. - expanded inline: superstate - 'new tab/page': the content of the subprocess node Where e.g. a doubleclick on a collapsed one opens it expanded inline or on a new tab... Bruce Silver writes about this in http://www.brsilver.com/wordpress/2008/09/15/concepts-and-terminology-in-... Regarding the connection of a sequenceflow into a node I have no clear picture yet... if I find the time I'll try to read about it. Terminology wise: 1) & 2) Yes, I agree and it might be nothing more than 'getting used to' or pose a real problem. Not sure yet 3) I often 'abused' the task node, since in many of the processes I worked on could be either 'signalled' via an incomming b2b message or a from a form on a web page that was completed by a human. So this to me is no problem... this 'abuse' will continue I think after reading about the private, abstract, global processes and the B2B arena. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205961#4205961 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205961

16 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by scott.stark＠jboss.org

"emuckenhuber" wrote : | I think it should have be symmetric whether you do copyContent or not and always have: | ... | | So for isCopyContent == false - we should have a own transient deployment profile - which gets activated / deactivated by the DeploymentManager. | ... | Yes, I agree. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205960#4205960 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205960

16 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2009