[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.... ]
Tom Fonteyne updated WFLY-1309:
-------------------------------
Description:
Setup two boxes:
- on one, run domain mode (full-ha) -> domain controller
- on the other, configure host.xml to point to the DC, and run the host controller
Now in CLI:
# add the group:
/server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
# create server and set a prop
batch
/host=slave1/server-config=i1:add(group=slaves,auto-start=false)
/host=slave1/server-config=i1/system-property=env:add(value=dev)
run-batch
results in:
JBAS010839: Operation failed or was rolled back on all servers.
Debugging (on EAP 6.0.1) showed the real reason:
activeStep.response = (org.jboss.dmr.ModelNode) {
"outcome" => "failed",
"failure-description" => "JBAS010850: No handler for operation
composite at address [
(\"host\" => \"slave1\"),
(\"server\" => \"i1\")
]",
"rolled-back" => true
}
More debugging led to :
org.jboss.as.controller.AbstractOperationContext
seems to be where the rollback is set. When debugging, I found that the constructor always sets
ModelController.OperationTransactionControl transactionControl
but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
// Allow any containing TransactionControl to vote
final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
and ref becomes a rollback.
I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
was:
Setup two boxes:
- on one, run domain mode (full-ha) -> domain controller
- on the other, configure host.xml to point to the DC, and run the host controller
Now in CLI:
# add the group:
/server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
# create server and set a prop
batch
/host=slave1/server-config=i1:add(group=slaves,auto-start=false)
/host=slave1/server-config=i1/system-property=env:add(value=dev)
run-batch
results in:
JBAS010839: Operation failed or was rolled back on all servers.
Debugging (on EAP 6.0.1) showed the real reason:
activeStep.response = (org.jboss.dmr.ModelNode) {
"outcome" => "failed",
"failure-description" => "JBAS010850: No handler for operation
composite at address [
(\"host\" => \"slave1\"),
(\"server\" => \"test\")
]",
"rolled-back" => true
}
More debugging led to :
org.jboss.as.controller.AbstractOperationContext
seems to be where the rollback is set. When debugging, I found that the constructor always sets
ModelController.OperationTransactionControl transactionControl
but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
// Allow any containing TransactionControl to vote
final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
and ref becomes a rollback.
I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
> CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1309
> URL: https://issues.jboss.org/browse/WFLY-1309
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha1
> Environment: wildfly build from a git clone on 2013-05-02
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
> Attachments: host-domain-controller.xml, host-slave.xml
>
>
> Setup two boxes:
> - on one, run domain mode (full-ha) -> domain controller
> - on the other, configure host.xml to point to the DC, and run the host controller
> Now in CLI:
> # add the group:
> /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
> # create server and set a prop
> batch
> /host=slave1/server-config=i1:add(group=slaves,auto-start=false)
> /host=slave1/server-config=i1/system-property=env:add(value=dev)
> run-batch
> results in:
> JBAS010839: Operation failed or was rolled back on all servers.
> Debugging (on EAP 6.0.1) showed the real reason:
> activeStep.response = (org.jboss.dmr.ModelNode) {
> "outcome" => "failed",
> "failure-description" => "JBAS010850: No handler for operation
> composite at address [
> (\"host\" => \"slave1\"),
> (\"server\" => \"i1\")
> ]",
> "rolled-back" => true
> }
> More debugging led to :
> org.jboss.as.controller.AbstractOperationContext
> seems to be where the rollback is set. When debugging, I found that the constructor always sets
> ModelController.OperationTransactionControl transactionControl
> but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
> // Allow any containing TransactionControl to vote
> final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
> and ref becomes a rollback.
> I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
> But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.... ]
Tom Fonteyne commented on WFLY-1309:
------------------------------------
consider it a typo sorry :( I did several tests - looks like I copy pasted results from two. I corrected the original report to read "i1" throughout.
> CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1309
> URL: https://issues.jboss.org/browse/WFLY-1309
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha1
> Environment: wildfly build from a git clone on 2013-05-02
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
> Attachments: host-domain-controller.xml, host-slave.xml
>
>
> Setup two boxes:
> - on one, run domain mode (full-ha) -> domain controller
> - on the other, configure host.xml to point to the DC, and run the host controller
> Now in CLI:
> # add the group:
> /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
> # create server and set a prop
> batch
> /host=slave1/server-config=i1:add(group=slaves,auto-start=false)
> /host=slave1/server-config=i1/system-property=env:add(value=dev)
> run-batch
> results in:
> JBAS010839: Operation failed or was rolled back on all servers.
> Debugging (on EAP 6.0.1) showed the real reason:
> activeStep.response = (org.jboss.dmr.ModelNode) {
> "outcome" => "failed",
> "failure-description" => "JBAS010850: No handler for operation
> composite at address [
> (\"host\" => \"slave1\"),
> (\"server\" => \"i1\")
> ]",
> "rolled-back" => true
> }
> More debugging led to :
> org.jboss.as.controller.AbstractOperationContext
> seems to be where the rollback is set. When debugging, I found that the constructor always sets
> ModelController.OperationTransactionControl transactionControl
> but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
> // Allow any containing TransactionControl to vote
> final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
> and ref becomes a rollback.
> I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
> But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-1313) IllegalStateException in CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction.teardown()
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-1313?page=com.atlassian.jira.plugin.... ]
jaikiran pai closed WFLY-1313.
------------------------------
Resolution: Rejected
This can't really be handled with a proper graceful shutdown in place. Closing this issue.
Here's a related conversation:
{quote}
[7:53:32 PM] Jaikiran Pai: i needed some input from stuart, but it's too late for him now. jason, can you take a look at this commit that I added for https://issues.jboss.org/browse/WFLY-1313
[7:53:42 PM] Jaikiran Pai: https://github.com/jaikiran/jboss-eap/commit/b73c7bb197a08fa8962cdb4e9a52...
[7:53:46 PM] Jaikiran Pai: does it look fine to you?
[7:57:32 PM] Stuart Douglas: I am here
[7:57:38 PM] Jaikiran Pai: nice! :)
[7:57:58 PM] Jaikiran Pai: it looks like the components are misisng a dep on that CCM service
[7:58:14 PM] Stuart Douglas: nah
[7:58:27 PM] Jaikiran Pai: something else?
[7:58:30 PM] Stuart Douglas: we have the same problem in the web with the CCM
[7:58:33 PM] Stuart Douglas: its not a dep issue
[7:58:56 PM] Stuart Douglas: but threads that are in flight when undelpoy starts cause a problem once the CCM is shut down
[7:58:58 PM] Jaikiran Pai: from what i see, the CCM service is stopped even when the EJB component is still alive
[7:59:12 PM] Jaikiran Pai: right
[7:59:45 PM] Jaikiran Pai: shouldn't we really stop the CCM (service) from being shut down until the dependent component is undeployed fully?
[8:00:03 PM] Jaikiran Pai: a.k.a add a dep?
[8:00:07 PM] Stuart Douglas: This comes down to graceful shutdown
[8:01:06 PM] Stuart Douglas: Its not a dep problem, as unless we add a gate to the components that dont all them to shutdown untill all threads are done processing you can't stpo this
[8:01:40 PM] Stuart Douglas: If a remote invocation is in progress on an EJB the EJB can still shutdown
[8:02:00 PM] Stuart Douglas: And for the most part the invocation just progresses as normal
[8:02:21 PM] Stuart Douglas: but onces the CCM is in there you get that exception which makes the non-graceful shutdown much more visible
[8:02:53 PM] Jaikiran Pai: yeah, that's actually what started showing up once i added that test which does exactly this
[8:03:18 PM] Jaikiran Pai: i.e. trigger an undeploy which takes time to complete and at the same time keep firing requests to that deployment remotely
[8:03:25 PM] Stuart Douglas: yea
{quote}
> IllegalStateException in CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction.teardown()
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1313
> URL: https://issues.jboss.org/browse/WFLY-1313
> Project: WildFly
> Issue Type: Bug
> Components: EE, JCA
> Reporter: jaikiran pai
> Assignee: jaikiran pai
>
> The following exception was reported on lightning:
> {code}
> Caused by: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.connector.deployers.ra.processors.CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction.teardown(CachedConnectionManagerSetupProcessor.java:105)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:62)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
> The tests involved a EJB deployment and the EJBs were being invoked when the undeployment was in progress (@see SlowUndeploymentRemoteFailoverTestCase).
> It looks like the CachedConnectionManager service isn't being added as a dependency on the components (like EJBs) which rely on it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-1314) Add a management operation to let remote EJB clients know that a particular server is no longer capable of handling a EJB request
by jaikiran pai (JIRA)
jaikiran pai created WFLY-1314:
----------------------------------
Summary: Add a management operation to let remote EJB clients know that a particular server is no longer capable of handling a EJB request
Key: WFLY-1314
URL: https://issues.jboss.org/browse/WFLY-1314
Project: WildFly
Issue Type: Feature Request
Components: EJB
Reporter: jaikiran pai
Assignee: jaikiran pai
While looking into another issue WFLY-1313 we realized that it might be a good idea to allow admins to have some kind of management operation where they could say that a particular server will no longer accept EJB invocations (for all deployments or maybe just a specific deployment). This would then allow the admins to issue such a operation and the remote EJB clients (via the EJB client library) would then realize that, they should no longer send out requests to that server node. This way the admins can then even undeploy the deployment or shutdown the server without having to worry about EJB invocations coming in and failing in-flight due to deployment being currently undeployed.
>From a EJB client library point of view, this essentially is a explicit "module unavailable" notification that the server will trigger to its connected clients.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-1309:
----------------------------------------
Thanks, Tom. Something does not compute here though:
JBAS010850: No handler for operation composite at address [ (\"host\" => \"slave1\"), (\"server\" => \"test\") ]", "rolled-back" => true }
This indicates there is a host named "slave1" out there with a host.xml containing <server-config> element for a server named "test". I'm seeing host.xml files for a "master" and a "slave10" neither of which have a server-config for "test".
What I'm looking for is all the host config files from the moment *just before* you begin executing the CLI steps in the description.
The most important thing I want to see is info about the config of this "test" server/
> CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1309
> URL: https://issues.jboss.org/browse/WFLY-1309
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha1
> Environment: wildfly build from a git clone on 2013-05-02
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
> Attachments: host-domain-controller.xml, host-slave.xml
>
>
> Setup two boxes:
> - on one, run domain mode (full-ha) -> domain controller
> - on the other, configure host.xml to point to the DC, and run the host controller
> Now in CLI:
> # add the group:
> /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
> # create server and set a prop
> batch
> /host=slave1/server-config=i1:add(group=slaves,auto-start=false)
> /host=slave1/server-config=i1/system-property=env:add(value=dev)
> run-batch
> results in:
> JBAS010839: Operation failed or was rolled back on all servers.
> Debugging (on EAP 6.0.1) showed the real reason:
> activeStep.response = (org.jboss.dmr.ModelNode) {
> "outcome" => "failed",
> "failure-description" => "JBAS010850: No handler for operation
> composite at address [
> (\"host\" => \"slave1\"),
> (\"server\" => \"test\")
> ]",
> "rolled-back" => true
> }
> More debugging led to :
> org.jboss.as.controller.AbstractOperationContext
> seems to be where the rollback is set. When debugging, I found that the constructor always sets
> ModelController.OperationTransactionControl transactionControl
> but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
> // Allow any containing TransactionControl to vote
> final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
> and ref becomes a rollback.
> I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
> But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-963) NoSuchMethodError pushOwner(ServiceTarget, ServiceName)
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-963?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins edited comment on WFLY-963 at 5/3/13 11:49 AM:
---------------------------------------------------------------
Jeff was able to solve his case, but the workaround used was to adapt WritableServiceBasedNamingStore logic from (un)bind, IMHO we should have an API for modules/subsystems, possible options are:
1) Accept bindings done without WritableServiceBasedNamingStore.pushOwner(), i.e. WritableServiceBasedNamingStore bind() and unbind() would accept and understand that if owner not set then the op is related to a unmanaged bind, i.e. unbind not done automatically. This could open the door for bugs based on developer forgetting to use pushOwner() when they should, but a good thing of this solution is that the API is just the standard JNDI, and no particular properties need to be set, which means code could be easily ported to somewhere else. In this case there is no chance of defining a specific service target to add the binding service, so we would have to use the naming store's service, but then we are talking about unmanaged.
2) Provide an alternative JNDI context impl, available by passing config properties on new InitialContext(properties). No doors open for misusage, dependency only on JNDI api, but needing special properties is not much different than having a proprietary API. No chance of defining a specific service target too.
3) Provide a proprietary API, something like WritableServiceBasedNamingStore.unmanagedBind(String name, Object value). A solution that clearly defines the functionality with little chance of misusage, which could even allow ops targeting a specific service target, but there is the dependency on AS Naming, so not much better than using MSC's BinderService.
>From the AS Naming developer point of view I'm more into 3) but standard JNDI api failing like in this issue could make 1) more desirable, even if more dangerous.
was (Author: emmartins):
Jeff was able to solve his case, but the workaround used was to adapt WritableServiceBasedNamingStore logic from (un)bind, IMHO we should have an API for modules/subsystems, possible options are:
1) Accept bindings done without WritableServiceBasedNamingStore.pushOwner(), i.e. WritableServiceBasedNamingStorethis's bind() and unbind() would understand that if owner not set then the op is related to a unmanaged bind, i.e. unbind not done automatically. This could open the door for bugs based on developer forgetting to use pushOwner() when they should, but a good thing of this solution is that the API is just the standard JNDI, and no particular properties need to be set, which means code could be easily ported to somewhere else. In this case there is no chance of defining a specific service target to add the binding service, so we would have to use the naming store's service, but then we are talking about unmanaged.
2) Provide an alternative JNDI context impl, available by passing config properties on new InitialContext(properties). No doors open for misusage, dependency only on JNDI api, but needing special properties is not much different than having a proprietary API. No chance of defining a specific service target too.
3) Provide a proprietary API, something like WritableServiceBasedNamingStore.unmanagedBind(String name, Object value). A solution that clearly defines the functionality with little chance of misusage, which could even allow ops targeting a specific service target, but there is the dependency on AS Naming, so not much better than using MSC's BinderService.
>From the AS Naming developer point of view I'm more into 3) but standard JNDI api failing like in this issue could make 1) more desirable, even if more dangerous.
> NoSuchMethodError pushOwner(ServiceTarget,ServiceName)
> ------------------------------------------------------
>
> Key: WFLY-963
> URL: https://issues.jboss.org/browse/WFLY-963
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Reporter: Jeff Yu
> Assignee: Eduardo Martins
>
> In the JBoss AS-7.1.1.Final, I used the following code to do the JNDI binding/unbinding from the modules (not deployed in the deployment folder).
>
>
> public class JndiRegistry {
>
> private static final Log LOG= LogFactory.getLog(JndiRegistry.class);
>
> public static void bindToJndi(String name, Object object) {
> ServiceTarget serviceTarget = CurrentServiceContainer.getServiceContainer();
> if (serviceTarget != null) {
> WritableServiceBasedNamingStore.pushOwner(serviceTarget);
> try {
> InitialContext context = new InitialContext();
> context.bind(name, object);
> } catch (NamingException e) {
> LOG.error("Error in binding the object in JNDI.");
> }
> }
> }
>
> public static void unbindFromJndi(String name){
> ServiceTarget serviceTarget = CurrentServiceContainer.getServiceContainer();
> if (serviceTarget != null) {
> WritableServiceBasedNamingStore.pushOwner(serviceTarget);
> try {
> InitialContext context = new InitialContext();
> context.unbind(name);
> } catch (NamingException e) {
> LOG.error("Error in unbinding the object from JNDI.");
> }
> }
> }
>
> }
>
>
>
> With the EAP 6.1.0.Alpha, I am getting the error of "
> Caused by: java.lang.NoSuchMethodError: org.jboss.as.naming.WritableServiceBasedNamingStore.pushOwner(Lorg/jboss/msc/service/ServiceTarget;[Lorg/jboss/msc/service/ServiceName;)V",
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-963) NoSuchMethodError pushOwner(ServiceTarget, ServiceName)
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-963?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins commented on WFLY-963:
--------------------------------------
Jeff was able to solve his case, but the workaround used was to adapt WritableServiceBasedNamingStore logic from (un)bind, IMHO we should have an API for modules/subsystems, possible options are:
1) Accept bindings done without WritableServiceBasedNamingStore.pushOwner(), i.e. WritableServiceBasedNamingStorethis's bind() and unbind() would understand that if owner not set then the op is related to a unmanaged bind, i.e. unbind not done automatically. This could open the door for bugs based on developer forgetting to use pushOwner() when they should, but a good thing of this solution is that the API is just the standard JNDI, and no particular properties need to be set, which means code could be easily ported to somewhere else. In this case there is no chance of defining a specific service target to add the binding service, so we would have to use the naming store's service, but then we are talking about unmanaged.
2) Provide an alternative JNDI context impl, available by passing config properties on new InitialContext(properties). No doors open for misusage, dependency only on JNDI api, but needing special properties is not much different than having a proprietary API. No chance of defining a specific service target too.
3) Provide a proprietary API, something like WritableServiceBasedNamingStore.unmanagedBind(String name, Object value). A solution that clearly defines the functionality with little chance of misusage, which could even allow ops targeting a specific service target, but there is the dependency on AS Naming, so not much better than using MSC's BinderService.
>From the AS Naming developer point of view I'm more into 3) but standard JNDI api failing like in this issue could make 1) more desirable, even if more dangerous.
> NoSuchMethodError pushOwner(ServiceTarget,ServiceName)
> ------------------------------------------------------
>
> Key: WFLY-963
> URL: https://issues.jboss.org/browse/WFLY-963
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Reporter: Jeff Yu
> Assignee: Eduardo Martins
>
> In the JBoss AS-7.1.1.Final, I used the following code to do the JNDI binding/unbinding from the modules (not deployed in the deployment folder).
>
>
> public class JndiRegistry {
>
> private static final Log LOG= LogFactory.getLog(JndiRegistry.class);
>
> public static void bindToJndi(String name, Object object) {
> ServiceTarget serviceTarget = CurrentServiceContainer.getServiceContainer();
> if (serviceTarget != null) {
> WritableServiceBasedNamingStore.pushOwner(serviceTarget);
> try {
> InitialContext context = new InitialContext();
> context.bind(name, object);
> } catch (NamingException e) {
> LOG.error("Error in binding the object in JNDI.");
> }
> }
> }
>
> public static void unbindFromJndi(String name){
> ServiceTarget serviceTarget = CurrentServiceContainer.getServiceContainer();
> if (serviceTarget != null) {
> WritableServiceBasedNamingStore.pushOwner(serviceTarget);
> try {
> InitialContext context = new InitialContext();
> context.unbind(name);
> } catch (NamingException e) {
> LOG.error("Error in unbinding the object from JNDI.");
> }
> }
> }
>
> }
>
>
>
> With the EAP 6.1.0.Alpha, I am getting the error of "
> Caused by: java.lang.NoSuchMethodError: org.jboss.as.naming.WritableServiceBasedNamingStore.pushOwner(Lorg/jboss/msc/service/ServiceTarget;[Lorg/jboss/msc/service/ServiceName;)V",
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-23) Quoted script parameters are not properly parsed in the bash script
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-23?page=com.atlassian.jira.plugin.sy... ]
RH Bugzilla Integration commented on WFLY-23:
---------------------------------------------
James Perkins <jperkins(a)redhat.com> made a comment on [bug 918030|https://bugzilla.redhat.com/show_bug.cgi?id=918030]
The "./jboss-eap-6.1/bin/domain.sh: darwin: not found" issue is fixed, but I'm not sure what to do about the Solaris issue. I only have OpenSolaris 11 installed in a VM. I'm downloading OracleSolaris 10 now and I'll see if I can replicate the errors. We'll see if it works in VirtualBox.
My initial guess is that maybe "readlink -m" doesn't always return a value on Solaris 10.
> Quoted script parameters are not properly parsed in the bash script
> -------------------------------------------------------------------
>
> Key: WFLY-23
> URL: https://issues.jboss.org/browse/WFLY-23
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 8.0.0.Alpha1
>
>
> Quotes are added to parameters passed via the command line. When checking the parameters for the {{jboss.server.base.dir}}, {{jboss.server.config.dir}} and {{jboss.server.log.dir}} properties quoted parameters are not found.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months