[JBossWS] - Re: WebServices logging
by alessio.soldano＠jboss.com
The documentation clearly says the Record Management is available starting from version 2.0.3. Which version of JBossWS are you using? The version that comes with JBoss 4.2.2.GA is 2.0.1.SP2, thus if you did not change anything about that, you would simply need to upgrade to a more recent version. In that case, take a look at the supported target containers matrix : http://jbossws.jboss.org/mediawiki/index.php?title=Supported_Target_Conta...
This said, for a simple use of the Record Management with Native stack you don't need to do anything special besides going to the JMX console and activate the recording flag in the already installed LogRecorder instance for you endpoint. No implementation required, no changes to the endpoint config required (assuming you're using one of the provided endpoint configuration). The LogRecorder will simply log every message going through your endpoint into your server.log.
Further customization and usescases are explained in the documentation, I'm sure you'll understand everything easily once you have that stuff (i.e. you using a jbossws version that has that). Also consider taking a look at the testcases in the sources, package org.jboss.test.ws.management.recording.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215153#4215153
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215153
15 years, 11 months
[Microcontainer] - Re: Attachments eligible for being passed to the deployers?
by jaikiran
So here's the real question :)
Do attachments to component contexts of an unit get treated the same way? Do these attachments to component contexts get passed onto the deployers? From what i see this is not the case.
Here's the example:
// This one doesn't do much and is not of much relevance in this
| // example. It just creates a component which can be consumed
| // by our component deployer (MyComponentDeployer - see next)
| public class TestDeployer extends AbstractDeployer
| {
|
| public TestDeployer()
| {
| setStage(DeploymentStages.POST_CLASSLOADER);
| // this is our output which is consumed by MyComponentDeployer
| setOutput(TestAttachment.class);
| // some input - not relevant in this example
| setInput(JBossMetaData.class);
| }
|
| // creates a component to the unit and adds an attachment to the component
| // so that the MyComponentDeployer can consume it
| public void deploy(DeploymentUnit unit) throws DeploymentException
| {
| DeploymentUnit comp = unit.addComponent("something");
| comp.addAttachment(TestAttachment.class, new TestAttachment("hello"));
| logger.info("Added attachment to component in unit " + unit);
| }
| }
|
// This one is important - this deployer is a component only deployer
| // and works on the component that was created by our earlier TestDeployer
| public class MyComponentDeployer extends AbstractDeployer
| {
|
|
| public MyComponentDeployer()
| {
| setStage(DeploymentStages.REAL);
| // the attachment that was added to the component by our earlier deployer
| // will be our input
| setInput(TestAttachment.class);
| // we work only on components
| setComponentsOnly(true);
| }
|
| // Here we just add an attachment to the unit (which acutally is an component)
| // Any further deployers (MyFinalDeployer - see next) will use this attachment
| // as input
| public void deploy(DeploymentUnit unit) throws DeploymentException
| {
| logger.info("Deploying unit : " + unit);
| // doesn't work
| unit.addAttachment(AnotherType.class, new AnotherType());
| }
|
| }
|
|
// This one (tries to) consumes the attachment that was added by the component
| // deployer (see above)
| public class MyFinalDeployer extends AbstractDeployer
| {
| private static Logger logger = Logger.getLogger(OneMoreDeployer.class);
|
| public MyFinalDeployer()
| {
| setStage(DeploymentStages.REAL);
| // the attachment that was added by the component deployer
| setInput(AnotherType.class);
|
| }
|
| // never reaches here.
| public void deploy(DeploymentUnit unit) throws DeploymentException
| {
| logger.info("Deploying another type " + unit);
|
| }
|
| }
|
|
|
There are 3 deployers involved here:
1) The TestDeployer creates a component to an unit and also attaches an attachment to the component (works fine)
2) The MyComponentDeployer consumes this component context and additionally creates an attachment to it (works fine/or maybe not).
3) MyFinalDeployer is supposed to consume the attachment created in #2, but it never does. This deployer is considered "not relevant".
The only way i could get this to work was to add the attachment to the parent of the component context in #2. So:
public class MyComponentDeployer extends AbstractDeployer
| {
|
| // I don't know why i need to add the attachment to the
| // parent. But it works, so let's for the time being do that
| public void deploy(DeploymentUnit unit) throws DeploymentException
| {
| logger.info("Deploying unit : " + unit);
| // here - i'm clueless, the attachment needs to be added to parent for some reason
| // Note, this is a component deployer and works on component context
| unit.getParent().addAttachment(AnotherType.class, new AnotherType());
| }
|
| }
|
Doing this makes MyFinalDeployer (in #3) "relevant" and the unit is passed on the deploy method of MyFinalDeployer.
So the question is - what am i missing? :)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215152#4215152
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215152
15 years, 11 months
[JBoss Messaging] - Re: Bridge error because of network problems also influences
by mclu
Some further test:
I also tried to kill instance A, so a local instance. Then also C is influenced once. After my 50s retrytime the bridge to C is back again.
(no, C is not the problem. It also happes the other way round)
After restarting instance A the connection from X to A is reestablished but then it failed 2 time again with messages like the example above. Between the reconnect and disconnect it always took around 3 seconds:
| 09:44:41,421 INFO [Bridge] jboss.messaging:name=OutgoingBridge_AEOSA,service=Bridge Succeeded in reconnecting to servers
| 09:44:44,437 WARN [Bridge] jboss.messaging:name=OutgoingBridge_AEOSA,service=Bridge Detected failure on connection
| javax.jms.JMSException: Failure on underlying remoting connection
| at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:102)
| at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:641)
| 09:44:44,484 ERROR [ClosedInterceptor] ClosedInterceptor.ClientSessionDelegate[c7-xv1z6xrf-1-k6dr6xrf-d1wvvl-2227p4]: method getXAResource() did not go through, the interceptor is CLOSED
| 09:44:44,484 WARN [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.rollbackxaerror] [com.arjuna.ats.internal.jta.resources.arjunacore.rollbackxaerror] XAResourceRecord.rollback - xa error XAException.XAER_NOTA
| 09:44:44,484 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_54] - Top-level abort of action -5601fdfe:82d:49af8f92:ea received TwoPhaseOutcome.FINISH_ERROR from <ClassName:RecordType.JTA_RECORD>
| 09:44:44,484 WARN [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.rollbackxaerror] [com.arjuna.ats.internal.jta.resources.arjunacore.rollbackxaerror] XAResourceRecord.rollback - xa error XAException.XAER_NOTA
| 09:44:44,484 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_54] - Top-level abort of action -5601fdfe:82d:49af8f92:ea received TwoPhaseOutcome.FINISH_ERROR from <ClassName:RecordType.JTA_RECORD>
| 09:44:44,484 WARN [Bridge] jboss.messaging:name=OutgoingBridge_AEOSA,service=Bridge Will retry after a pause of 50000 ms
| 09:45:34,609 INFO [Bridge] jboss.messaging:name=OutgoingBridge_AEOSA,service=Bridge Succeeded in reconnecting to servers
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215139#4215139
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215139
15 years, 11 months