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

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by scott.stark＠jboss.org

"emuckenhuber" wrote : | This has not been discussed a lot, therefore how you exactly are going to specify the profile is still open :) | This depends on how the structure of "common/*" looks like, maybe we have some aliasing for the jboss-profile-source. But in general you should just need to say <jboss-profile> and the profiles, deployments which are required. The test.xml example is a little too file based to be a general metadata view unless the source can be taken as just a URI to be resolved by something. So I would expect test.xml to be something like: | <profiles | xmlns="urn:jboss:profileservice:profiles:1.0" | name="profiles"> | | <profile name="immutable"> | <profile-source> | <source>jboss-deployers:javaee5-deployers</source> | <source>jboss-bootstrap:conf/bootstrap.xml</source> | </profile-source> | <sub-profile>ejb3</sub-profile> | <deployment>myEjb3Deployment.ear</deployment> | </profile> | | <hotdeployment-profile name="mutable"> | <profile-source> | <source>${jboss.server.home.url}deploy</source> | <source>${jboss.server.home.url}deploy2</source> | </profile-source> | <sub-profile>immutable</sub-profile> | </hotdeployment-profile> | | <maven-profile name="maven" xmlns="urn:jboss:profileservice:profile:maven:1.0"> | <profile-source> | <source>http://repository.jboss.org/maven2</source> | </profile-source> | <sub-profile>hotdeployment</sub-profile> | <deployment>org.jboss.jboss-profileservice:profileservice-spi-6.0.0-GA</deployment> | </maven-profile> | | </profiles> | where both the profile metadata and interpretation will be a function of the factory that matches up to the metadata. This is an aside to the original question of how to create the profile. So, if creation of a profile is a process of supplying the profile metadata to a factory, that would be fine. It would not matter whether the bootstrap and core profiles are immutable as I don't expect the profile to be iteratively created in terms of adding core deployers, bootstrap deployments. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214305#4214305 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214305

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by bstansberry＠jboss.com

"emuckenhuber" wrote : Well i think so about xml defined profiles. I mean most of our deployments should come from a "commons/*" location, which leaves the user there with a mostly empty deployers, deploy, farm folder. | Therefore those profiles would be immutable (no addContent, hd scanning). | I guess there will be still the usual folders, where you can add custom deployers, deployments yourself. | And of course i did not say that those cannot be clustered. Just immutable, for our bundled stuff :) Yeah, if content is stored in "common/**" it's a bit off if one of the profiles started using that shared content then updates the content to match another node in the cluster. At least we shouldn't ship a configuration that works that way. But I'm pretty sure some people will reconfigure stuff so that happens. :) After all use of common/** is just a mechanism to reduce our download size. I doubt many people are actually booting multiple production instances off the same unzipped JBoss distribution. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214300#4214300 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214300

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by emuckenhuber

"scott.stark(a)jboss.org" wrote : | How would one define a new profile with a collection of standard jbossas deployments then? | Hmm not sure if got your question, but once going to a xml description of profiles, the creation of the profiles should be based on the meta data type and the corresponding factories: e.g. http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/resources/parsing... This has not been discussed a lot, therefore how you exactly are going to specify the profile is still open :) This depends on how the structure of "common/*" looks like, maybe we have some aliasing for the jboss-profile-source. But in general you should just need to say <jboss-profile> and the profiles, deployments which are required. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214278#4214278 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214278

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by scott.stark＠jboss.org

"emuckenhuber" wrote : | Well i think so about xml defined profiles. I mean most of our deployments should come from a "commons/*" location, which leaves the user there with a mostly empty deployers, deploy, farm folder. | Therefore those profiles would be immutable (no addContent, hd scanning). | I guess there will be still the usual folders, where you can add custom deployers, deployments yourself. | And of course i did not say that those cannot be clustered. Just immutable, for our bundled stuff :) | How would one define a new profile with a collection of standard jbossas deployments then? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214274#4214274 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214274

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by emuckenhuber

"bstansberry(a)jboss.com" wrote : | Not so sure about the "in future most of the xml defined profiles" part. Most of the stuff currently in deploy/ could logically go in farm/ and thus get the behavior of a newly starting node automatically syncing the subprofile content with the cluster.[1] That implies that in the xml defined profiles, most of the subprofiles could logically use clustering behavior, even those that specify deployers. At least conceptually that's true; whether we'd ever configure things that way in a stock config is a different issue. But I bet users will try it even if we don't. | Well i think so about xml defined profiles. I mean most of our deployments should come from a "commons/*" location, which leaves the user there with a mostly empty deployers, deploy, farm folder. Therefore those profiles would be immutable (no addContent, hd scanning). I guess there will be still the usual folders, where you can add custom deployers, deployments yourself. And of course i did not say that those cannot be clustered. Just immutable, for our bundled stuff :) I guess i will provide a few OOB profiles with their factories, so that it should be fairly easy to get most of the cominations. "bstansberry(a)jboss.com" wrote : | I'm mostly just trying to point out some of the subtleties of my use case here so you know about them. :-) | Highly appreciated, thanks :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214272#4214272 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214272

17 years, 2 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: [JBAS-5221] tx-connection-factory/no-tx-connection-facto

by scott.stark＠jboss.org

Sounds good View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214270#4214270 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214270

17 years, 2 months

1
0
0 / 0

[Design the WSRP implementation] - Re: status on WSRP inside portlet container?

by chris.laprun＠jboss.com

If you are interested in this feature, vote for it on JIRA... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214269#4214269 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214269

17 years, 2 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: [JBAS-5221] tx-connection-factory/no-tx-connection-facto

by jesper.pedersen

After having looked at this - I think that the best solution would to be refactor the layer such that the management view ends up with a view that represents the deployment (-ds.xml). This would mean that the 'config-property' entry will only be available for tx-connection-factory and no-tx-connection-factory deployments. That way we don't have two ways of doing the same thing - like Emanuel's post shows. Lets focus on getting the management view for datasource deployments correct for 5.1.0.Beta1 as they will cover most deployment. If time permit we can look into incorporating specific property descriptions. We can pick up the remaining areas for the 5.1.0.CR1 release. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214266#4214266 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214266

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by bstansberry＠jboss.com

"emuckenhuber" wrote : But i don't think a deploymentRepository is required for all profiles (e.g. the bootstrap profile, or in future most of the xml defined profiles). Not so sure about the "in future most of the xml defined profiles" part. Most of the stuff currently in deploy/ could logically go in farm/ and thus get the behavior of a newly starting node automatically syncing the subprofile content with the cluster.[1] That implies that in the xml defined profiles, most of the subprofiles could logically use clustering behavior, even those that specify deployers. At least conceptually that's true; whether we'd ever configure things that way in a stock config is a different issue. But I bet users will try it even if we don't. [1] One of the things I'm going to do locally as a test this week is move most of the stuff out of deploy/ into farm/; just leave the deploy/cluster stuff needed to let the clustered deployment repository work. Start the server and see what happens. :-) anonymous wrote : I mean in the end it's then depending on your implementation what it should support and if it uses a deploymentRepository. Very true. And AFAICT it shouldn't be a big deal to have a DeploymentRepository backed profile that also isn't "mutable" after startup. So I don't think having a Profile impl that isn't backed by a repository breaks anything for me; it's just another impl. I'm mostly just trying to point out some of the subtleties of my use case here so you know about them. :-) anonymous wrote : Just that the isMutable() is used by the DeploymentManager to determine which profiles are a possible target to deploy content to. | But i don't think i have time to do that for 'Beta1', but most probably for CR1. | Yeah, keep it simple. :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214255#4214255 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214255

17 years, 2 months

1
0
0 / 0

[Design of JBoss Build System] - ant version check in 4.2 branch

by scott.stark＠jboss.org

Just running ant to build the https://svn.jboss.org/repos/jbossas/branches/Branch_4_2 its failing to recognize the ant 1.7.1 version as it does not appear to see the ant.version system property: | BUILD FAILED | /Users/svn/JBossAS/branches/Branch_4_2/tools/etc/buildmagic/buildmagic.ent:28: Unsupported Ant version: | | ${ant.version} | | Please install a version which is compatible with Ant 1.6.5 or 1.7.1. | | Total time: 1 second | [512][valkyrie: build]$ type ant | ant is hashed (/usr/bin/ant) | [513][valkyrie: build]$ ant -version | Apache Ant version 1.7.1 compiled on June 27 2008 | I can build with the bundled ant 1.6.5 fine. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214249#4214249 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214249

17 years, 2 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 March 2009