embedded and bootsrap dependencies

[emuckenhuber]

Briefly looking at the embedded and bootstrap project i noticed:

public interface JBossASEmbeddedServer
 extends
 JBossASBasedServer<JBossASEmbeddedServer, JBossASServerConfig>,
 Container

I think this is a embedded specific use case of how to enable users to deploy stuff, which should not be in the bootstrap project itself - rather defined by an api in the embedded project. Especially since the impl has a dependencies on the vdf.
IMHO a embedded release adding features should be independent of a bootstrap release.

Any thoughts? Maybe i just missed a previous discussion about this.

[alrubinger]

Well, that's confined to jboss-bootstrap-api-embedded, which is for the Embedded AS. When we say "the bootstrap project itself", what does that really mean?

* Generic Bootstrap? (Lifecycle and some config w/ minimal dependencies)
* MC Bootstrap (Starts and installs the Kernel)
* AS Bootstrap (AS-specific configs and grammar)

There isn't presently an "Embedded" project with any code now. groupId org.jboss.embedded at the moment contains a build config, an assembly, and test suites. All other code is shuffled off to other components. The reason for this is because I allowed org.jboss.embedded stuff to depend upon AS itself. Embedded AS Bootstrap doesn't need to depend upon AS for anything.

I'm open to an argument that the Embedded Bootstrap belongs under the Embedded groupId. But regardless of where the code lives in SVN or its groupId, we can still do releases of it without affecting the AS.

S,
ALR

[emuckenhuber]

"ALRubinger" wrote:

Well, that's confined to jboss-bootstrap-api-embedded, which is for the Embedded AS. When we say "the bootstrap project itself", what does that really mean?

With "the bootstrap project itself" i mean everything in projects/bootstrap/*.

"ALRubinger" wrote:

I'm open to an argument that the Embedded Bootstrap belongs under the Embedded groupId. But regardless of where the code lives in SVN or its groupId, we can still do releases of it without affecting the AS.

Basically the piece i'm arguing should not be there is the "extends Container", as this pulls a user deployment-api into bootstrap.
This is what i'd like to see in a separate embedded project, as it might be easier to keep this backward compatible. So i'm not much concerned about this affecting AS - it's rather the other way around.

[alrubinger]

"emuckenhuber" wrote:
This is what i'd like to see in a separate embedded project, as it might be easier to keep this backward compatible. So i'm not much concerned about this affecting AS - it's rather the other way around.

From what I can tell, we'd just be moving the problem, as we have to integrate somewhere. Seems what you're proposing is moving jboss-bootstrap-api-embedded and impl-embedded under the org.jboss.embedded umbrella again (where I had it originally, actually ;)).

As currently set up, this won't affect AS as AS doesn't depend upon it. And AS can't really affect it either; that's why there's the TMPDPL "Container" API. Now api-embedded doesn't have a dependency on even VDF. Container becomes the locked SPI.

Does that solve the backwards-compat issue sufficiently for you?

S,
ALR

[emuckenhuber]

"ALRubinger" wrote:

From what I can tell, we'd just be moving the problem, as we have to integrate somewhere. Seems what you're proposing is moving jboss-bootstrap-api-embedded and impl-embedded under the org.jboss.embedded umbrella again (where I had it originally, actually ;)).

Yes, i think it's better under it's own umbrella :)

"ALRubinger" wrote:

As currently set up, this won't affect AS as AS doesn't depend upon it. And AS can't really affect it either; that's why there's the TMPDPL "Container" API. Now api-embedded doesn't have a dependency on even VDF. Container becomes the locked SPI.

Does that solve the backwards-compat issue sufficiently for you?

Hmm, we could briefly talk about the deployable as well - as i can tell for sure that ProfileService won't expose a VDF deployment.
Maybe we want to just rename the VfsVdfDeployableFactory to a DeployableFactory? In the end it should not really matter what deployable is created and i don't think there should be 2 different types - like VdfDeployable and PSDeployable - at the same time.

Is there an additional use for the deployable in general? I guess it would be used when having a DSL attaching the actual deployment descriptor instead of a reference to a xml?

[OT] out of curiosity - it seems that when creating a deployable you are creating a zip out of the shrinkwrap in-memory archive.
When i first looked at the archive stuff - i thought you are directly deploying this in-memory VirtualFile. Is there a specific reason why you don't do that?
Well, as it gets zipped it could be interesting to use that also in standalone testing.

[alrubinger]

"emuckenhuber" wrote:
Yes, i think it's better under it's own umbrella :)

OK. I'm still not seeing the advantage. Will find you on #jboss-dev tomorrow so we can discuss some more.

"emuckenhuber" wrote:
Hmm, we could briefly talk about the deployable as well - as i can tell for sure that ProfileService won't expose a VDF deployment.
Maybe we want to just rename the VfsVdfDeployableFactory to a DeployableFactory? In the end it should not really matter what deployable is created and i don't think there should be 2 different types - like VdfDeployable and PSDeployable - at the same time.

More to discuss. Keep in mind the idea behind Container/Deployable is to be as generic as possible, as the TCK299 test utils will be leveraging the same contract.

"emuckenhuber" wrote:
[OT] out of curiosity - it seems that when creating a deployable you are creating a zip out of the shrinkwrap in-memory archive.
When i first looked at the archive stuff - i thought you are directly deploying this in-memory VirtualFile. Is there a specific reason why you don't do that?
Well, as it gets zipped it could be interesting to use that also in standalone testing.

Yeah. VFS is a filesystem abstraction, but MemoryFile does not support the full range of VFSFile operations in the same fashion as from a traditional flat file root. So we use ShrinkWrap to represent the mutable object view of an archive and ultimately flush that to a temp file which becomes the deployable. At that point, Embedded/AS doesn't know/care the difference from where the archive originally came from,and the Embedded suite passed without further issues. For instance, JBossWeb and Hibernate both have filesystem dependent code and may fail when using MemoryFile.

S,
ALR

[emuckenhuber]

"ALRubinger" wrote:

"emuckenhuber" wrote:
Yes, i think it's better under it's own umbrella :)

OK. I'm still not seeing the advantage. Will find you on #jboss-dev tomorrow so we can discuss some more.

Sure, we can talk there as well. Let's put it the other way around - i'm actually wondering why it's part of bootstrap.
Maybe i have just a different view of what the bootstrap project is about, as for me it's a contract for starting/stopping a server - therefore i think a deployment-api is misplaced there. Technically you can most probably achieve the same no matter where you put it - i was just confused seeing that in bootstrap. Maybe it's the most natural thing for other users, don't know :)

"ALRubinger" wrote:

"emuckenhuber" wrote:
Hmm, we could briefly talk about the deployable as well - as i can tell for sure that ProfileService won't expose a VDF deployment.
Maybe we want to just rename the VfsVdfDeployableFactory to a DeployableFactory? In the end it should not really matter what deployable is created and i don't think there should be 2 different types - like VdfDeployable and PSDeployable - at the same time.

More to discuss. Keep in mind the idea behind Container/Deployable is to be as generic as possible, as the TCK299 test utils will be leveraging the same contract.

Yes, i agree that it should be a generic contract. That's why i was suggesting having something like:

DeployableFactory
{
 Deployable create(String name, InputStream archive);
 Deployable create(File archive);
 Deployable create(URL archive);
}

Maybe as well one for creating a Deployable based on a shrinkwrap archive. All the code is already there. I'm just suggesting not using the name VfsVdfDeployableFactory - as the name somehow implies a VFS and VDF based deployable.
In the end which deployable is created should not matter for the user and is more related to what embedded can deploy.

"ALRubinger" wrote:

"emuckenhuber" wrote:
[OT] out of curiosity - it seems that when creating a deployable you are creating a zip out of the shrinkwrap in-memory archive.
When i first looked at the archive stuff - i thought you are directly deploying this in-memory VirtualFile. Is there a specific reason why you don't do that?
Well, as it gets zipped it could be interesting to use that also in standalone testing.

Yeah. VFS is a filesystem abstraction, but MemoryFile does not support the full range of VFSFile operations in the same fashion as from a traditional flat file root. So we use ShrinkWrap to represent the mutable object view of an archive and ultimately flush that to a temp file which becomes the deployable. At that point, Embedded/AS doesn't know/care the difference from where the archive originally came from,and the Embedded suite passed without further issues. For instance, JBossWeb and Hibernate both have filesystem dependent code and may fail when using MemoryFile.

I see, well i thought the VFS temp thingy would take care of creating (real) temp files usable by jboss.web - but i know that you had other issues as well. So i was just curios about if it would have worked without zipping it. As said it makes it also usable for remote deployments, so it actually seems to be a good thing.

[alrubinger]

"emuckenhuber" wrote:

DeployableFactory
{
 Deployable create(String name, InputStream archive);
 Deployable create(File archive);
 Deployable create(URL archive);
}

Maybe as well one for creating a Deployable based on a shrinkwrap archive. All the code is already there. I'm just suggesting not using the name VfsVdfDeployableFactory - as the name somehow implies a VFS and VDF based deployable.
In the end which deployable is created should not matter for the user and is more related to what embedded can deploy.

I'm actually in the process of removing the ShrinkWrap dep from tmpdpl-api, so I'll do this at the same time. Then I'll introduce some more tmpdpl-shrinkwrap integration components. With the name changes you suggest.

S,
ALR

[alrubinger]

"ALRubinger" wrote:
I'm actually in the process of removing the ShrinkWrap dep from tmpdpl-api, so I'll do this at the same time.

https://jira.jboss.org/jira/browse/TMPDPL-8

S,
ALR

[alrubinger]

To the point of the Bootstrap API being used for configuration and deployment, Emanuel and I discussed a bunch in #jboss-dev:

"#jboss-dev@Freenode" wrote:
<ALR> emuckenhuber: Still here?
<emuckenhuber> ALR: yes
<ALR> emuckenhuber: I remember why I didn't give Embedded its own API
<ALR> Because I'd essentially be either duplicating the AS Bootstrap or leaking it.
<ALR> emuckenhuber: End user needs to start/stop/config
<emuckenhuber> ALR: with config you mean the ServerConfig thingy ?
<ALR> emuckenhuber: Yep.
<emuckenhuber> ALR: yes, but this is currently based on system properties and should be mostly handled by the domain model in future - so i'm not sure how much of configuration part we can reuse for AS6
<ALR> emuckenhuber: Ideally very little.
<ALR> emuckenhuber: IMHO the sysprop approach is a way of circumventing a proper API
<ALR> emuckenhuber: Another thing we can consider: Plug through with the current model as we have it, and revisit config for AS6.
<ALR> emuckenhuber: Where we provide a hook into the unified domain model.
<ALR> emuckenhuber: And bootstrap>PS becomes integrated.
<ALR> Then we can draw a line. Bootstrap starts/stops a server. Configutation is some runtime model which is exposed by a real "Server". The Server *has* a bootstrap, *has* a PS domain config, *has* deployment hooks....
<ALR> And we piece together a full view via composition
<emuckenhuber> ALR: we can also do that later if you prefer
<emuckenhuber> ALR: it's just that i noticed that this will change in future
<jpederse> ALR, emuckenhuber: composition is important
<ALR> emuckenhuber: I think so. Because we can still move forward with what we have in the current model. In the future I'll def want to make PS a first-class citizen here.
<ALR> But a lot of those hooks aren't yet available.
<ALR> And major version changes ie 5 to 6, I like to use as an opportunity to break down walls and build the cleanest thing we can rather than support components across major versions.
<emuckenhuber> ALR: yes that was at least the plan, i just can tell that profileservice nor bootstrap will depend on each other so far
<ALR> emuckenhuber: Cool, I'll make some notes of the discussion on the post

So the conclusion there is that the Embedded API will remain an extension of the bootstrap and we'll revisit at 6. The approach there may be:

Embedded Server delegates start/stop to Bootstrap, Deployment to TMPDPL, and configuration to PS. All composed together and behind locked SPIs.

S,
ALR