[brian.stansberry]

"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. :-)

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. :-)

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. :)

[emuckenhuber]

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.

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 :)

[starksm64]

"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?

[emuckenhuber]

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-tests/parsing/test.xml

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.

[brian.stansberry]

"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.

[starksm64]

"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.

[emuckenhuber]

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.

The meta data does not dictate a uri as source. The only thing required is a profileFactory, which can handle a specific implementation of ProfileMetaData to create a ProfileImpl. Resolving should also be part of this implementation. As this is something which does not necessarily apply to all profiles in the same way.

This test is just a quick prototype and is not finalized at all. Basically i just was testing the XmlAnyElement - so that you can plugin your own meta data implementation.

[starksm64]

"emuckenhuber" wrote:

This test is just a quick prototype and is not finalized at all. Basically i just was testing the XmlAnyElement - so that you can plugin your own meta data implementation.

Ok, great.