arquillian integration question
by John Mazzitelli
Lukas,
http://rhq-project.org/display/RHQ/Arquillian+Integration+For+Agent
+Plugins#ArquillianIntegrationForAgentPlugins-Restrictions
You mention here that we can define more than one PC configuration. In
our test class, how do we tell it which one we want?
For example, in the example you give on that wiki, you have two PCs
defined:
... <container qualifier="pc" default="true"> ...
... <container qualifier="another-pc"> ...
Obviously, "pc" is used by default due to the default="true" attribute. But if my test wants to use teh "another-pc" - how do I indicate this in my test?
12 years, 2 months
Confusing AS4 Plugin Functionality
by Stefan Negrea
Hello Everybody,
I am still working on content system BZs and came across something interesting and unique to JBoss AS4 plugin. I had a lengthy talk with Ian and the conclusion was that it will require a little bit of rework.
The AS4 plugin has a concept of backup/restore for applications. The backup is done when creating a new application but only when the newly created application is to be deployed on top of an existing application. The original application is kept in a folder/file with .bak appended to its name. There is an option in the deploy wizard regarding backup creation, the default value is no. Every application has an operation called "revert". This works only if the .bak file is present on the disk. If the user calls revert that operation is non-reversible, only one single revert is possible.
Now there are a couple of problems with this:
1) Content redeployments using the content tab do not create the .bak file. The revert works only in the narrow case described above.2
2) Unless the user knows exactly what the backup setting does, it will probably go unnoticed (and no backup is done).
2) Lets suppose the .bak was created. And lets suppose a user redeploys content (through the content system) a couple of times and then calls revert. The app will be reverted to the content prior to creating the new app. So the revert operation is very misleading. It's not reverting to previous content but to content prior to resource creation.
3) It is not very clear to users when the revert operation is available.
4) This functionality can only be found in the AS4 plugin. No other plugin has a similar concept implemented.
5) If the application is large, there is no way to delete the .bak file from RHQ. The only workaround is to manually delete the file afterwards.
My proposal:
1) Remove this functionality completely. The revert concept should be implemented at content system level.
2) Remove the revert operation from web applications.
2) Prevent deployments of applications on top of existing applications. If an app is already deployed on disk at the same location then fail the operation to create a new resource. This will eliminate the need to have a .bak file on disk.
Here are some reasons to support my proposal:
1) AS4 plugin functionality will be aligned with Tomcat and AS5.
2) No more confusing revert operations and use cases.
3) Simpler and easier to maintain plugin code.
4) Make a clear design choice that this functionality should be implemented at content system level.
5) The code that does the actual deployments will be nearly identical between AS4, AS5 and Tomcat and can be refactored to a common location.
Does my proposal make sense? Is there anything I am missing with regards to this confusing functionality? Is there anybody actually using .bak files and revert?
Thank you,
Stefan Negrea
Software Engineer
12 years, 2 months
create child resource and configuration
by Heiko W.Rupp
Hi,
When I create a child resource, the <resource-configuration> is taken as configuration for that child
(not the <plugin-config> ! as in the case of manual-add ) - is there a way to signal that I either want to use
the <plugin-config> instead OR that the <resource-config> is only for create-child, but not to be used otherwise?
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
12 years, 2 months
AUTO: David A. Webster is out of the office (returning 03/02/2012)
by David A. Webster
I am out of the office until 03/02/2012.
Training New Hires today and tomorrow. Be back in the office Monday, March
5th
Note: This is an automated response to your message "Review of JMX Plugin
JVM Attach Feature (BZ-703557)" sent on 3/1/2012 2:35:15 PM.
This is the only notification you will receive while this person is away.
**
This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies.
**
12 years, 2 months
"Read-only", monitoring agent
by Costel Cosman
Hi,
About the proposal to have a "read-only", monitoring agent (See RFC:
https://bugzilla.redhat.com/show_bug.cgi?id=783911), I added a comment
with an additional idea:
===========================================================================
It seems a good idea to have a "read-only" agent.
The proposed solution (to disable the "write" features like Configuration and
Provisioning and leave only "read" features like Monitoring) still has an
issue: malicious code can be embedded in the monitoring part of the plugins.
An idea would be to sign the plugin JAR. The agent will check the signature
every time a plugin update is performed. The signature will guarantee that the
plugins come only from a trusted source.
============================================================================
What do you think about this idea ?
Regards,
Costel
12 years, 2 months