[Design of POJO Server] - Re: The DeploymentManager and ProfileService
by emuckenhuber
"scott.stark(a)jboss.org" wrote :
| Ok, so an issue with that is how do we store admin edits of such profiles?
|
I think in this case the Profile itself would need to take care about it, because for a VFSDeployment we can check the metadata paths,
if there were modifications and don't apply admin edits. But we don't have a generic way to do that for a normal Deployment.
But in the end if we have something like (e.g. in the ManagementView)
| removeAttachments(ProfileDeployment d, String attachmentName);
|
this could also work.
"scott.stark(a)jboss.org" wrote :
| What's missing is a generic ProfileBootstrap that can have different ways of specifying subprofiles that should be included. For example, the deployers and base services would be specified via criteria, user apps specified via a uri to one or more apps defined in a jboss tools project. I'm going to review the changes in trunk tonight, but it is probably more of a notion of a resolver that I'm thinking of.
|
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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206155#4206155
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206155
15 years, 2 months
[Design of POJO Server] - Re: The DeploymentManager and ProfileService
by scott.stark@jboss.org
"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.
|
Ok, so an issue with that is how do we store admin edits of such profiles?
"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)
|
Right, the profiles I'm working on don't have URIs either as they are described in terms of criteria that need to be resolved.
"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 :)
|
What's missing is a generic ProfileBootstrap that can have different ways of specifying subprofiles that should be included. For example, the deployers and base services would be specified via criteria, user apps specified via a uri to one or more apps defined in a jboss tools project. I'm going to review the changes in trunk tonight, but it is probably more of a notion of a resolver that I'm thinking of.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206151#4206151
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206151
15 years, 2 months
[Design the new POJO MicroContainer] - Re: Deployment cleanup & modifications
by alesj
Thinking about it even more ...
"alesj" wrote :
| How do you then handle these three calls:
| (1) root::getChildren()
| (2) root::getChild("myapp.ear/myweb-ui.war/WEB-INF/lib/ui.jar/org/acme/FooBar.class")
| (3) VFS::getRoot(new URL("${jboss.deploy}/myapp.ear/myweb-ui.war/WEB-INF/lib/ui.jar/org/acme/FooBar.class"))
|
| I would expect for (1) not to use temp, otherwise I won't know when my original myapp.ear was deleted.
| For (2) and (3) I would like to use all the existing temps I could get in order not to re-unpack something.
|
I guess this shouldn't be such a huge problem as I see it. :-)
If you have a handle to some VirtualFile, use it as it is
- be it client view or temp, it's up to the type of the handle.
If I get an URL, try to use as much as possible.
Hence treating URLs as server side objects.
The 'inconsistency' will always be there.
e.g. VirtualFile that was fetched via navigation vs. direct URL access
"alesj" wrote :
| So, during structure recognition, we already get a few unpacked nested jars.
| Then it turns out that the user requested this app to be temped.
|
| To be true to our unpacking/temp performace reasons (= reuse as much as possible),
|
This is also quite easy to avoid (to some extent). :-)
The existing unpack/temp info should just hold the ref to the new File,
which should be later on re-used.
Here we would still have two versions of wiring,
one from client the other from temp,
since incorporating re-wiring would perhaps even be wrong.
But at least it would be done on the same unpacked/temped copies,
hence no need to spend any time doing that.
But this two new 'findings' shouldn't stop you from
adding some content to this problems. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206131#4206131
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206131
15 years, 2 months