[Design of JBoss Build System] - Re: [jboss-as-control-plugin] Deploy/Undeploy Mojos
by ALRubinger
"astubbs" wrote : "ALRubinger" wrote : "astubbs" wrote : Why is maven-jboss-deploy-plugin module commented out in the aggregator pom?
| | At the moment I'm leaning towards a Deploy Plugin with Mojos for local, remote, exploded, etc. Your thoughts?
| |
| yes I would be inclined to agree with you.
| Plus you've already created a new component for it in Jira anyway ;)
OK, we'll move forward then with JBASMP-7.
"astubbs" wrote : there are places where log4j has been used instead of AbstractMojo's.
JBASMP-8.
"astubbs" wrote : "astubbs" wrote : Feature decision: should we allow the user to deploy to a server location which isn't running? Atm, the plugin will throw a build error after it deploys (should be before?), if it cannot contact the server.
| I suppose this is going to depend on the mechanism for deploying in different ways. Perhaps the plugin could only allow it for hard deploys.
Go ahead and open a Feature Request. :)
"astubbs" wrote : Why in ServerController#stopServer (and other places) are we using sysout instead of a proper logger?"astubbs" wrote : Ah right then - this is something that I should fix.
I'd hold off on that unless we've got good reason to need a logger. Generally, JBoss as an organization/codebase is very big, and we don't make a habit of changing code written by others without a real need. Specifically, I wonder if System.out was used because the Ant tasks that share this code work better under that setup.
"astubbs" wrote : Another proposal regarding is IMO JbossAsControlCreateConfigurationMojo should copy the configuration from resources/jbossasconf (or something of that nature) vs resources/conf as conf as ambiguous."ALRubinger" wrote :
| | This is configurable by way of the "overlayLocation" property that may be passed to the Mojo. "src/main/resources" seemed an intelligent default, no?
| IMHO, no because the resources directory is meant for "Application/Library resources". So say you have a web application with a Spring configuration file or message files, you would put those in the resources directory - but of course you don't want that included in your jboss overlay, so you would put your jboss overlay somewhere else.
|
| I know it's configurable, but the most common use case would be having project resources and _not_ having a custom configuration overlay, thus resources should be reserved for actual application resources.
Right, this is a good point. So let's go with your proposal to simply change the default overlay location to "src/jbossas/resources" in keeping with something that looks and feels like a Maven convention.
JBASMP-9.
"astubbs" wrote : I know, I just wanted to include all that (Groovy) stuff to show you as apart of the *ahem* _review_ process.
You get no points for one-upping your reviewer in terms of the latest fad technology. :)
"astubbs" wrote : +1 porting (JMX Deployment Code) to server-manager to start with.
JBASM-6.
Also, there's no "+1" or votes at JBoss. As a matter of principle, decisions should be made based on merit (@see Wikipedia Meritocracy), and I've been chewed out in public forums for voting before. Word to the wise.
The flip side to this, of course, is who gets to define merit. :)
"astubbs" wrote : For this case, I don't think we should change the current approach, I vote for reverting to the old pom, adding deploy / undeploy tasks to the plugin configuration (as is the 'full' profile now), and replace the 'deploy/undeploy' profiles with proper integration tests in the project.
For now, OK. Maybe we'll add a profile-driven POM as an alternative later.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164909#4164909
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164909
17 years, 8 months
[Design of JBoss Build System] - Re: [jboss-as-control-plugin] Deploy/Undeploy Mojos
by astubbs
Forum reply:
"ALRubinger" wrote :
| "astubbs" wrote : Why is maven-jboss-deploy-plugin module commented out in the aggregator pom?
| | Did you intend for the deployment mojo's to be kept in a project of that name?
| | if so - why not keep them in the control plugin? For the moment, as per your comment on the issue, they have been added to the maven-jboss-as-control-plugin module.
|
| No idea; twas months ago before we've resurrected this now. :). This brings up a good opportunity to discuss whether these should be in a separate plugin, or simply a Mojo within AS Control. At the moment I'm leaning towards a Deploy Plugin with Mojos for local, remote, exploded, etc. Your thoughts?
|
Well I suppose it all depends how complex the deployment code is going to get. But if it will eventually support all the things' you've mentioned, and undoubtedly more, then yes I would be inclined to agree with you.
Plus you've already created a new component for it in Jira anyway ;)
"ALRubinger" wrote :
| "astubbs" wrote : Why aren't we using log4j directly instead of using the AbstractMojo#getLog() mojo logger?
|
| AbstractMojo already defines a logging mechanism, so why add another? This is also what's used by the Maven Plugins like Surefire, etc. Aside from accepting "CharSequence" as an argument, I don't know why this design was chosen; this question was unanswered for me on Codehaus #maven and I never pursued it.
|
Sorry, that should have read why *are* (not aren't). Of course you are correct, but there are places where log4j has been used instead of AbstractMojo's.
"ALRubinger" wrote :
| "astubbs" wrote : If both the start and deploy goals execution phase is 'pre-integration-test' - how can we assure that the start goal runs before deploy? Simply ordering the execution tasks so that 'start' is before 'deploy' appears to work, but it doesn't ensure the order.
|
| More generically: "How do I ensure proper order when two goals are tied to the same lifecycle phase?". The order of definition in the POM is the deciding factor here, though I've been advised to rely on this at a minimum. Had some talks today w/ Maven devs to see if placing a new "ordinal" field on the execution makes sense to play tiebreaker in these cases. Apparently the addition of new lifecycles is already on a wishlist somewhere (like MC does. :) ).
|
cool.
"ALRubinger" wrote :
| "astubbs" wrote : During development, debugging the mojo's in eclipse worked very well, except sometimes I would get caught with this error:
| | "The PluginDescriptor for the plugin" "was not found. Should have been in realm: ClassRealm"
| | It was very finicky and would sometimes disappear, but I couldn't nail down what was causing it.
| | At one point, doing an eclipse clean and doing a mvn install on the projects caused it to start occurring again. At this point I still haven't gotten the goals working from inside eclipse. Note, they work fine from the cli.
| | If you're interested in the problem I can post more info.
|
| I haven't come across this; perhaps related to class files falling out of sync within Eclipse during development of the Plugin itself (ie. Wouldn't be seen by users)?. Yes, hang onto this, and if we need to file a bug we'll do so in a new JIRA Project for the Plugins.
|
According to the #maven guys it's a bug, and I upgraded to the development m2eclipse version and it's seems to have mostly disappeared.
"ALRubinger" wrote :
| "astubbs" wrote : Feature decision: should we allow the user to deploy to a server location which isn't running? Atm, the plugin will throw a build error after it deploys (should be before?), if it cannot contact the server.
|
| Sounds like a good feature, but would only work for hard-deploy (ie. non-JMX) on local machines (unless the remote machine had some other mechanism available through which we could copy, like SFTP).
|
Right. It was useful during the development of the hard deploy method of course, but wouldn't work otherwise. Although, come to think of it, a normal user wouldn't be deploying to jbossAS without having it running anyway - pretty useless. But none the less, some people might want it.
I suppose this is going to depend on the mechanism for deploying in different ways. Perhaps the plugin could only allow it for hard deploys.
"ALRubinger" wrote :
| "astubbs" wrote : Why in ServerController#stopServer (and other places) are we using sysout instead of a proper logger?
| | In order to stick with the current convention, I have also used sysout in ServerController.
|
| Don't know, the author has since retired JBoss. :)
Ah right then - this is something that I should fix.
"ALRubinger" wrote : "astubbs" wrote : P.s. apologies if that was too much rant ;)
|
| BS. You'd do it all over again.
|
;)
"ALRubinger" wrote : "astubbs" wrote : Another proposal regarding is IMO JbossAsControlCreateConfigurationMojo should copy the configuration from resources/jbossasconf (or something of that nature) vs resources/conf as conf as ambiguous.
|
| This is configurable by way of the "overlayLocation" property that may be passed to the Mojo. "src/main/resources" seemed an intelligent default, no?
|
IMHO, no because the resources directory is meant for "Application/Library resources". So say you have a web application with a Spring configuration file or message files, you would put those in the resources directory - but of course you don't want that included in your jboss overlay, so you would put your jboss overlay somewhere else.
I know it's configurable, but the most common use case would be having project resources and _not_ having a custom configuration overlay, thus resources should be reserved for actual application resources.
"ALRubinger" wrote :
| Groovy Mojos
|
| See above, Gradle. I'll keep these configurations posted as patched, but each patch should try to address one issue alone; this makes reverts and tracking much easier. Already we're biting off too much in terms of scope - release early, release often. :)
|
I know, I just wanted to include all that stuff to show you as apart of the *ahem* _review_ process.
"ALRubinger" wrote :
| jboss-server-manager-2.patch
|
| I've committed the change provided to fix spaces in Win32 classpaths:
|
| http://jira.jboss.com/jira/browse/JBASM-2
|
| Regarding the WarDeployer, this isn't the mechanism I'd had in mind.
|
| * This class is a simple File copy utility/wrapper for Commons FileUtils. What makes this specific to WAR Deployment?
|
Yes, that's why the code started off being a simple method inside the ServerController class :)
"ALRubinger" wrote : * I'd been incorrect in mentioning "existing logic in jboss-server-manager". What I'd been thinking of is within the jboss-test project, JBossTestServices.deploy(), which invokes upon the JMX Bus to Deploy a URL. @see http://anonsvn.jboss.org/repos/jbossas/projects/test/trunk/src/main/java/....
|
| So what I'd prefer to see is the Deploy Mojo to delegate to this kind of code. Because the Maven Plugins should not rely on jboss-test, we'd either have to rewrite this logic elsewhere or port it to server-manager, where both the Plugins and jboss-test could call upon it.
|
Ah yes I see that now.
The refactoring of that test code to the new dedicated deployer project should probably be apart of the same issue, or at least have a new issue created under the test project and linked.
+1 porting to server-manager to start with.
"ALRubinger" wrote :
| maven-jboss-as-control-example alternate pom.patch
|
| Good use of Profiles here to make a more user-friendly POM that's adaptable to different start/stop/deploy scenarios. However, the idea behind this project is simply to be self-documenting (and a free test mechanism to make sure the plugins work). Let's discuss this one more, I'd like to be convinced further why you believe we should change the "mvn clean install does everything" approach already in place. True users are going to be adapting our Plugins into their own POMs, remember, so I want this to be KISS and low barrier to entry for new users (who may also be new to Maven).
|
| Perhaps instead of replacing the existing POM, we add a profile-based one as well. Users then have some boilerplate better suited to real-world usage in addition to the simple startup provided by the original POM.
|
For this case, I don't think we should change the current approach, I vote for reverting to the old pom, adding deploy / undeploy tasks to the plugin configuration (as is the 'full' profile now), and replace the 'deploy/undeploy' profiles with proper integration tests in the project.
I look forward to hearing from you.
Regards,
Antony.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164906#4164906
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164906
17 years, 8 months
[Design of POJO Server] - Re: Regression in Smoke Test - WebIntegrationUnitTestCase
by ALRubinger
This patch brings the WebIntegrationUnitTestCase back in line:
Index: server/src/main/org/jboss/deployment/MappedReferenceMetaDataResolverDeployer.java
| ===================================================================
| --- server/src/main/org/jboss/deployment/MappedReferenceMetaDataResolverDeployer.java (revision 75930)
| +++ server/src/main/org/jboss/deployment/MappedReferenceMetaDataResolverDeployer.java (working copy)
| @@ -390,6 +390,8 @@
| {
| // Add ejb/vfsPath@iface
| String remote = sbean.getRemote();
| + String remoteJndiName = sbean.determineJndiName();
| + cdmd.addJndiName(remoteJndiName);
| String ifacePath = prefix + "@" + remote;
| if(endpointAlternateMap.containsKey(ifacePath))
| log.debug(ejbName+" duplicates remote: "+remote+", existing: "+endpointAlternateMap.get(ifacePath));
| @@ -451,6 +453,8 @@
| {
| // Add ejb/vfsPath@iface
| String local = sbean.getLocal();
| + String localJndiName = sbean.determineLocalJndiName();
| + cdmd.addJndiName(localJndiName);
| String ifacePath = prefix + "@" + local;
| if(endpointAlternateMap.containsKey(ifacePath))
| log.debug(ejbName+" duplicates local: "+local+", existing: "+endpointAlternateMap.get(ifacePath));
| @@ -537,8 +541,8 @@
| }
| // Add ejb/iface
| ifacePath = "ejb@" + remote;
| - if(endpointAlternateMap.containsKey(ifacePath))
| - log.debug(ejbName+" duplicates business-remote: "+remote+", existing: "+endpointAlternateMap.get(ifacePath));
| + if(endpointMap.containsKey(ifacePath))
| + log.debug(ejbName+" duplicates business-remote: "+remote+", existing: "+endpointMap.get(ifacePath));
| else
| {
| endpointAlternateMap.put(ifacePath, ejbCompID);
| @@ -946,7 +950,7 @@
| // Determine the jndi name for the reference interface
| String iface = getInterface(ref);
| //LegacyEjb3JndiPolicy policy = new LegacyEjb3JndiPolicy();
| - String containerJndiName = target.getBeanMetaData().determineResolvedJndiName(iface);
| + String containerJndiName = target.getBeanMetaData().determineJndiName();
| if(containerJndiName != null)
| ref.setResolvedJndiName(containerJndiName);
| }
I'm testing against some of the other testsuites locally now to see what impact this has elsewhere.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164904#4164904
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164904
17 years, 8 months
[Design of Clustering on JBoss] - HASingleton election and communication with mod_cluster
by bstansberry＠jboss.com
See http://wiki.jboss.org/wiki/en/ModClusterDesign
and http://wiki.jboss.org/wiki/Mod-Cluster_AS_integration for background.
HASingleton election refers to the process by which one of a set of nodes in a cluster is chosen as the one that will act as the singleton master. Upon receiving events generated by the AS's DistributedReplicantManager (DRM) service, each node in the cluster independently decides who will be the master using an HASingletonElectionPolicy impl. The key requirement of the policy impl is that its decision must be deterministic, so every node makes the same decision.
An HASingletonElection policy impl can use whatever data it wants to make its decision. The AS ships with a couple impls, the most basic of which uses the nodes' ordinal position in the current JGroups view to pick the master.
For the ModClusterService use case, there is an additional important factor in the election decision: a node's ability to communicate with the httpd servers that are proxying requests. A ModClusterService instance that can only communicate with one of four httpd servers is less desirable as the singleton master than one that can communicate with all four.
An added twist on this is certain httpd servers are more valuable than others. An htttpd server that has received configuration messages from the JBoss side is more valuable than one that hasn't. I call such a server "established". Imagine a scenario where there are 4 httpd servers, with only #1 and #2 established. Node A can communicate with #1 and #2, while B can communicate with #2 as well as a newly discovered #3 and #4> Node A should be the master even though B can communicate with more httpd servers. B has no ability to inform httpd #1 of future config changes or load balance factor changes, potentially leaving it in an invalid state.
The solution I see for managing the election process is to include information about a node's ability to communicate with the httpd servers inside the object it registers with the DistributedReplicantManager service. The object registered with DRM is available to HASingletonElectionPolicy impls, so they can use this information in their election decisions. So that's fairly straightforward.
What's more tricky is ensuring that timing effects in the recognition of httpd server topology changes don't lead to changes in the HASingleton master. For example:
a) httpd #5 comes on line and advertises itself. JBoss node B notices this slightly before master node A and takes over as singleton master, only to have A become the master again shortly later.
b) communication to httpd #3 is disrupted. JBoss node A (the master) notices this slightly before node B, and thus gets unelected as master, only to end up being re-elected shortly thereafter as B notices the trouble.
A possible protocol for handling this:
1) All nodes can "discover" httpd servers. "Discover" means learning the address:port of the httpd server either by parsing a config at startup, detecting one via an AdvertiseListener, or possibly by having a new address:port added by an administrative tool..
2) All nodes delegate to the current HASingleton master to manage the process of including new httpd servers in the available pool or removing leaving ones. So, if non-master node B discovers a new httpd server, it sends a message to master node A advising of the new server. Node B does nothing further to initiate communication with the new httpd server. It does keep a reference to the new/removed server address:port so it can resend the message to a new master if the current master fails.
3) The master node updates its MCMPHandler with the address/port of all discovered servers, whether discovered locally or via a message from another node. (The MCMPHandler has to be able to deal with duplicate adds).
4) During the regular status processing:
a) the master performs a status check on its own MCMPHandler -- i.e. adds newly discovered httpd servers, removes any it has been told no longer exist, tries to recover any in ERROR state via sending (cluster-wide) configuration data.
b) the master can now check how many httpd servers it knows about, how many are healthy, how many are established.
c) master sends an RPC to the cluster providing the address/port of all the currently known servers, along with a flag as to whether they are established. The other nodes use this to add/remove servers from their MCMPHandler, and then have their MCPHandler perform a status check. This status check *does not* involve sending configuration messages to recover any in ERROR state; instead an innocuous message like INFO should be sent. Goal is simply to test the ability to communicate with the httpd server. Only the master node sends configuration requests to the httpd side.
d) each non-master node checks how many httpd servers it knows about, how many are healthy, how many are established and responds to the RPC with this information.
e) the master now has all the information that would go into an HASingleton election. If the state of any of the nodes has changed, that node will need to update its object stored in the DistributedReplicantManager service. Any time the DRM is updated, a new election occurs. The question is in what order nodes should make their update. If the master node itself has changed state, it needs to decide whether to update the DRM before telling other nodes to do so, or to let the other nodes update first, and then make its update. If one choice or the other will result in the current master being reelected, the master should use that order for the next 2 steps:
f) master sends a message telling the other nodes to update the DRM with the state they sent in step d).
g) master updates the DRM with its current state
h) upon receipt of message from f), any reference to a new/removed server the node may have cached in step 2) above is cleared (since step d/e is completed, so all nodes in the cluster know about the new httpd server)
Failure handling in the above:
1) Step 2 above. Problem of dropping discovery messages. See 4.h. If a new master is elected before 4.h occurs, resend the discovery message to the new master.
2) Node doesn't respond to the 4.d RPC or responds with exception. In 4.g, the master instructs any such node to report itself to DRM as being in an error state; the election policy should treat such a node as being last in line for election as master.
3) Master fails after 4.e. The failure is detected so a new master is chosed, but the election is based on outdated information. Whoever is elected master, the next cycle the DRM will be updated with current information and a new election can occur, possibly resulting in yet another change in master. Need to decide how to deal with that; i.e. how should the "temporary" new master react? Depends on what a new master does anyway. If taking over as master doesn't involve any heavy work (i.e. refreshing all the configs on all the httpd servers), then this situation is harmless. At the moment I don't think taking over as master will involve heavy work.
4) Master fails after 4.f, doesn't complete 4.g. An election will occur after 4.f, using outdated data for the master node. Election can have two results: i) the master is re-elected, in which case the cluster just waits for the master to be suspected, forcing a new election. This is fine. ii) the master is not re-elected and a new node takes over as master, which is fine.
5) Master chooses 4.g before 4.f but fails after 4.g. Same as 3) above.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164903#4164903
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164903
17 years, 8 months
[Design of POJO Server] - Re: Regression in Smoke Test - WebIntegrationUnitTestCase
by ALRubinger
Though not relevant for the Web Integration tests, there's definitely some stuff amiss here. For example, I'm considering the following (as exposed by EJB3 Integration TestSuite "bank" test):
Index: server/src/main/org/jboss/deployment/MappedReferenceMetaDataResolverDeployer.java
| ===================================================================
| --- server/src/main/org/jboss/deployment/MappedReferenceMetaDataResolverDeployer.java (revision 75930)
| +++ server/src/main/org/jboss/deployment/MappedReferenceMetaDataResolverDeployer.java (working copy)
| @@ -390,6 +390,8 @@
| {
| // Add ejb/vfsPath@iface
| String remote = sbean.getRemote();
| + String remoteJndiName = sbean.determineResolvedJndiName(remote);
| + cdmd.addJndiName(remoteJndiName);
| String ifacePath = prefix + "@" + remote;
| if(endpointAlternateMap.containsKey(ifacePath))
| log.debug(ejbName+" duplicates remote: "+remote+", existing: "+endpointAlternateMap.get(ifacePath));
| @@ -451,6 +453,8 @@
| {
| // Add ejb/vfsPath@iface
| String local = sbean.getLocal();
| + String localJndiName = sbean.determineLocalJndiName();
| + cdmd.addJndiName(localJndiName);
| String ifacePath = prefix + "@" + local;
| if(endpointAlternateMap.containsKey(ifacePath))
| log.debug(ejbName+" duplicates local: "+local+", existing: "+endpointAlternateMap.get(ifacePath));
| @@ -537,8 +541,8 @@
| }
| // Add ejb/iface
| ifacePath = "ejb@" + remote;
| - if(endpointAlternateMap.containsKey(ifacePath))
| - log.debug(ejbName+" duplicates business-remote: "+remote+", existing: "+endpointAlternateMap.get(ifacePath));
| + if(endpointMap.containsKey(ifacePath))
| + log.debug(ejbName+" duplicates business-remote: "+remote+", existing: "+endpointMap.get(ifacePath));
| else
| {
| endpointAlternateMap.put(ifacePath, ejbCompID);
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164892#4164892
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164892
17 years, 8 months
[Design of POJO Server] - Regression in Smoke Test - WebIntegrationUnitTestCase
by ALRubinger
In changing JNDI mechanisms, I've introduced regressions into the WebIntegrationTestCase:
http://jboss.hudson.alrubinger.com/job/AS_TestSuite_Smoke_Tests/lastBuild...
The underlying error is:
Caused by: java.lang.IllegalStateException: Failed to find ContainerDependencyMetaData for interface: org.jboss.test.web.interfaces.StatelessSessionLocal
| at org.jboss.deployment.MappedReferenceMetaDataResolverDeployer.resolveEjbInterface(MappedReferenceMetaDataResolverDeployer.java:1034)
| at org.jboss.deployment.MappedReferenceMetaDataResolverDeployer.resolveEjbLocalRefs(MappedReferenceMetaDataResolverDeployer.java:856)
| at org.jboss.deployment.MappedReferenceMetaDataResolverDeployer.resolve(MappedReferenceMetaDataResolverDeployer.java:722)
| at org.jboss.deployment.MappedReferenceMetaDataResolverDeployer.internalDeploy(MappedReferenceMetaDataResolverDeployer.java:171)
My assumption is that some change needs to take place in MappedReferenceMetadataResolverDeployer.mapEjbs,but I can't seem to find the magic touch to make:
EndpointInfo info = resolver.getEndpointInfo(ifaceClass, EndpointType.EJB, vfsContext);
...not return null when given a valid interface. I see that:
ejb(a)org.jboss.test.cts.interfaces.StatefulSessionLocal
...is placed into the endpointAlternateMap just fine.
Any ideas what I'm missing?
Reproduce by:
testsuite$ ./build.sh one-test -Dtest=org.jboss.test.web.test.WebIntegrationUnitTestCase
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164882#4164882
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164882
17 years, 8 months