[Design of POJO Server] - Re: Sub-Profiles ProfileService changes
by emuckenhuber
"emuckenhuber" wrote :
| Basically all Profiles are getting registered as ON_DEMAND - so unless you don't have a dependency on it, it will not get activated unless you explicitly activate it :)
| But implicit dependencies with xml processing are also one issue i want to discuss here.
|
Well that's only half of the story - just to describe the problem a bit..
The main issue is basically the xml format with implicit dependencies and how you reference a profile -
so that profiles are started and stopped the correct order, or shutdown when a dependency is not satisfied anymore.
Which means you are right saying that something like mode="manual" would make sense.
As at the moment if you would define a clustering profile, like i did in the unit test case it is completely wrong (sorry for that).
In this case if you stop your clustering-hotdeployment directory it would shutdown also the "default" profile, as it is a dependency of that.
Even worse in the case i have now - where you basically shutdown all profiles which are defined after the clustering profile :)
We might want to add something to ignore this dependencies, but i still need to do some more work on that.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204463#4204463
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204463
17 years, 2 months
[Design of POJO Server] - Re: Using temp at undeploy
by alesj
Describing what I did.
Discussing whether it's not too much of a hack.
Currently the only way to apply ModificationType is via jboss-structure.xml/context/modification=temp|unpack|explode.
Which sounds a bit too limiting for a simple modification=temp instruction.
The way current structure recognition part of VDF works, we need to get that info before
StructureBuilder::populateContext is invoked in AbstractStructuralDeployers::determineStructure.
What I've done is introduced a new StructureDeployer,
which actually doesn't recognize the structure, but knows how to
recognize if there should be any modification.
| public class ModificationTypeStructureDeployer implements StructureDeployer
| {
| private List<ModificationTypeMatcher> matchers;
|
| public boolean determineStructure(StructureContext context) throws DeploymentException
| {
| if (matchers != null && matchers.isEmpty() == false)
| {
| for (ModificationTypeMatcher matcher : matchers)
| {
| if (matcher.determineModification(context))
| {
| break;
| }
| }
| }
| return false;
| }
|
| /**
| * Set modification type matchers.
| *
| * @param matchers the modification type matchers.
| */
| public void setMatchers(List<ModificationTypeMatcher> matchers)
| {
| this.matchers = matchers;
| }
|
| /**
| * Add modification type matcher.
| *
| * @param matcher the modification type matcher
| */
| public void addMatcher(ModificationTypeMatcher matcher)
| {
| if (matchers == null)
| matchers = new ArrayList<ModificationTypeMatcher>();
|
| matchers.add(matcher);
| }
|
| /**
| * Remove modification type matcher.
| *
| * @param matcher the modification type matcher
| */
| public void removeMatcher(ModificationTypeMatcher matcher)
| {
| if (matchers != null)
| {
| matchers.remove(matcher);
| }
| }
|
| public boolean isSupportsCandidateAnnotations()
| {
| return false;
| }
|
| public int getRelativeOrder()
| {
| return 1;
| }
| }
|
It runs right after DeclarativeStructureDeployer.
Actually the parts that recognize if modification should kick in are ModificationTypeMatcher implementations.
They add this information to StructureContext, which then passes it fwd in AbstractStructureDeployer::applyContextInfo
where the real ContextInfo is created or it's directly applied if one of the children sets modification to top level ContextInfo.
Here is an example of such ModificationTypeMatcher.
It matches any path in any deployment level.
| public class FileModificationTypeMatcher extends AbstractModificationTypeMatcher
| {
| private String[] paths;
|
| public FileModificationTypeMatcher(String... paths)
| {
| if (paths == null || paths.length == 0)
| throw new IllegalArgumentException("Null or empty paths");
|
| this.paths = paths;
| }
|
| /**
| * Get the starting file.
| *
| * @param structureContext the structure context
| * @return the startting file; where do we start checking for paths
| */
| protected VirtualFile getStartingFile(StructureContext structureContext)
| {
| return structureContext.getFile();
| }
|
| protected boolean isModificationDetermined(StructureContext structureContext)
| {
| VirtualFile startingFile = getStartingFile(structureContext);
| for (String path : paths)
| {
| try
| {
| if (startingFile.getChild(path) != null)
| return true;
| }
| catch (Exception e)
| {
| log.debug("Cannot determine modification type, cause: " + e);
| }
| }
| return false;
| }
| }
|
e.g. we could look for META-INF/web-beans.xml (still using the old name)
Wdyt, too much of a hack?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204460#4204460
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204460
17 years, 2 months
[Design of POJO Server] - Re: Sub-Profiles ProfileService changes
by emuckenhuber
"bstansberry(a)jboss.com" wrote :
| 1) Should "public void registerProfile(Profile profile)" instead be "public void registerProfile(ProfileMetaData profile)"? Let the ProfileService handle creation of the Profile from metadata. To make my HASingletonProfileManager work I needed to inject a reference to the ProfileFactory bean, which smells wrong.
|
Well the basic idea behind that was to be able to create a Profile outside the ProfileService.
The correct name for the ProfileFactory should be BootstrapProfileFactory (as this thing is just creating profiles for bootstrap).
But i was also thinking about creating a real ProfileFactory, which creates a Profile based on the ProfileMetaData - as this would also go well with some other updates on the meta data model.
"bstansberry(a)jboss.com" wrote :
| 2) Similar thing with "public void unregisterProfile(Profile profile)". I think the argument should be a ProfileKey.
|
Makes sense. I was not sure if this might could get a install/uninstall callback - but i'm not convinced that this makes sense anymore.
"bstansberry(a)jboss.com" wrote :
| 3) This is just a nit. Why releaseProfile(ProfileKey key) instead of inactivateProfile(ProfileKey key)?
|
I've updated the profileservice-spi today and named it 'deactivateProfile' - although if you say that inactivateProfile is better english, i can be easily convinced ;)
Still need to do a new release of the spi and commit some recent work i've been doing.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204455#4204455
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204455
17 years, 2 months
[Design of POJO Server] - Re: Sub-Profiles ProfileService changes
by bstansberry＠jboss.com
As I commented above, I think my HASingletonProfileManager class is the wrong approach. It's a temporary expedient.
It's wrong because something inside a Profile is adding content to the ProfileService at runtime. That means the ProfileService isn't aware of the content unless there is a running AS underneath it that deployed the HASingletonProfileManager.
So, we're better than the AS 5.0.0 case where the ProfileService is only aware on content if there is a running AS underneath *and* it's the master. But still not where we should be.
To get where we should be I think we need something like the MC ControllerMode concept added to ProfileMetaData:
<profiles name="deploy-hasingleton">
|
| <profile name="deploy-hasingleton-controller">
| <source type="mutable">${jboss.server.base.url}deploy</source>
| <deployment>cluster/deploy-hasingleton-jboss-beans.xml</deployment>
| </profile>
|
| <profile name="deploy-hasingleton-content" mode="MANUAL">
| <source type="mutable">${jboss.server.base.url}deploy-hasingleton</source>
| </profile>
|
| </profiles>
In this case "MANUAL" means just register the profile but don't activate it; activation requires that something call ProfileService.activateProfile().
Probably different terms than the ControllerModes would be better since the semantics are not identical.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204454#4204454
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204454
17 years, 2 months
[Design of POJO Server] - Re: Sub-Profiles ProfileService changes
by bstansberry＠jboss.com
I've gotten a prototype version of deploy-hasingleton functionality to work with the new SPI. Fundamental classes are:
http://anonsvn.jboss.org/repos/jbossas/trunk/cluster/src/main/org/jboss/h...
http://anonsvn.jboss.org/repos/jbossas/trunk/cluster/src/main/org/jboss/h...
The HASingletonProfileActivator is configured with the strings necessary to make up a ProfileKey and a ref to the ProfileService. It then exposes methods an HASingletonController can invoke when it becomes/stops being the master. Those methods call ProfileService.activateProfile() and releaseProfile().
The HASingletonProfileManager is a subclass that takes a List as a configuration element and uses that to create a Profile for the deploy-hasingleton content. I'll post separately about why I think this is wrong.
This code is committed but not used yet because making it work requires a change to AbstractProfileService that I want to discuss before committing. Will post separately on that as well.
Some comments on the SPI:
1) Should "public void registerProfile(Profile profile)" instead be "public void registerProfile(ProfileMetaData profile)"? Let the ProfileService handle creation of the Profile from metadata. To make my HASingletonProfileManager work I needed to inject a reference to the ProfileFactory bean, which smells wrong.
2) Similar thing with "public void unregisterProfile(Profile profile)". I think the argument should be a ProfileKey.
3) This is just a nit. Why releaseProfile(ProfileKey key) instead of inactivateProfile(ProfileKey key)?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204451#4204451
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204451
17 years, 2 months
[Design of JBoss Portal] - Re: Design of Portal Deployer
by mwringe
"alesj" wrote :
| I've added methods that allow you to add/remove metadata locations:
| - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=149197
|
| The deployers snapshot should be in the repo in a few hours.
| You can then test if this helps you.
unless I am missing something, this is never going to work with the way we are trying to do this.
JBoss Web only uses a small subject of all available 'metadata' files with the deployer, most things are directly handled internally. The deployer doesn't have anything to do with individual html files, jsp files, images, or tlds. I don't see how we can make it work in these situations without rewritting JBoss Web to be more dependent on the microcontainer.
FYI, I did try it with adding the metadata file to the deployment, it just that the deployment doesn't handle tld files, it's looked up through the web app's context which doesn't use the metadata location(see org.apache.jasper.compiler.TagLibraryInfoImpl.generateTLDLocation).
So back to the original TLD deployer. I don't really like how we have to access the tomcat deployment directory and move files around that way, but I don't see how we can modify the war in any other way.
I am missing some relevant information that would make using the metadata location make sense?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204440#4204440
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204440
17 years, 2 months