JBossDeveloper

"emuckenhuber" wrote:

"scott.stark@jboss.org" wrote:

If we completely abstract out the deployment and admin content into a deployment repository, then I can see a differentiation between a dynamic profile that is one define by root urls against the deployment repository vs a profile that allows modifications to both deployment collection make up and content changes.

One thing i don't like about the current implementation is that a profile is more defined over
it's DeploymentRepository than it is defined by itself (the actual profile).

Well i mean the implementation is not a big deal, just want to say that when talking about the definition of a Profile,
a DeploymentRepository should be optional.

On the other hand this is actually the main point of this thread. Basically how the DeploymentManager gets access
to the low level source of a mutable profile.
I'm not planning to change this yet - just an idea to think about :)

That's fine, I'll checkout the spi project and take a look until its in trunk.

"emuckenhuber" wrote:

Hmm, there are some use cases where you don't need any repository.
For example the transient application profile managed by the DeploymentManager.
This will be just a hashMap containing the isCopyContent == false deployments, so that they
are also visible in the ManagementView.
But it's still a independent profile, which can be activated / deactivated by the DeploymentManager.

"emuckenhuber" wrote:

Furthermore i think a VFS/uri does not make up a profile, as you still can could have a different (maybe static) profile,
where you create non-vfs based deployments - this is now also possible with the abstraction of ProfileDeployment (although not fully implemented)

"emuckenhuber" wrote:

Although i also think that there is something missing - but more in the sense of a ResourceDiscovery or ProfileSource.
Something where you can share the same source and don't need to maintain the profile root uris in each profile.
Maybe this also matches somehow to the work you want to do with a DeploymentRepository?

Can you provide some more information and/or use cases why you think this is not enough?
I mean maybe i'm just missing something :)

"emuckenhuber" wrote:

Yes there is definitely some work to do on the ProfileServiceBootstrap. Especially the one based on xml
needs some more work, if you want to look at that one.

public interface ProfileResolver
{
 public Collection<Profile> createProfiles(ProfileKey rootKey, Server server, Properties props)
 throws Exception;

}

I'm running into a few issues with trying to run an embedded AS testcase given just this type of unit test code:

@Profile(name="ejb3")
@ProfileDeployment(name="EmbeddedSessionUnitTest", pkg="org.jboss.test.ejb3.basic")
public class EmbeddedSessionUnitTest
 extends EmbeddedTestCase
{

 public EmbeddedSessionUnitTest(String name)
 {
 super(name);
 }

 public void testSession()
 throws Exception
 {
 InitialContext ctx = getInitialContext();
 String jndiName = "ejb3/basic/SimpleSessionBean";
 Object ref = ctx.lookup(jndiName);
 SimpleSession test = (SimpleSession) ref;
 test.ping();
 }
}

@Profile(name="naming")
public class EmbeddedTestCase
 extends AbstractTestCaseWithSetup
{
...
}

"emuckenhuber" wrote:

Hmm inmemory deployment - so that you don't need to create a physical jar?
Wouldn't that then be just another Profile implementation which actually creates the deployments?

"emuckenhuber" wrote:

I guess @Profile would be similar to the sub-profile in xml then - where you basically
just choose a required profile for the unit test?