[JBoss JIRA] (AS7-1338) Remote JNDI support for AS7
by Ed Keen (JIRA)
[ https://issues.jboss.org/browse/AS7-1338?page=com.atlassian.jira.plugin.s... ]
Ed Keen commented on AS7-1338:
------------------------------
I added a context.close() right after I send the message, and I am still seeing the error being logged. Since this does not affect functionality, we can wait until the patch makes its way through. Any chance this will go out with 7.1.0 Final?
> Remote JNDI support for AS7
> ---------------------------
>
> Key: AS7-1338
> URL: https://issues.jboss.org/browse/AS7-1338
> Project: Application Server 7
> Issue Type: Task
> Components: Naming
> Reporter: Richard Opalka
> Assignee: John Bailey
> Priority: Critical
> Labels: eap6_prd_req
> Fix For: 7.1.0.Final
>
>
> Add support for remote JNDI after all. It was agreed that:
> * Remote JNDI would run over Remoting
> * Remote JNDI for EJB is strictly a legacy access protocol, deprecated in favor of "ejb:"
> * The Remote JNDI service would proxy to a specific Context of the server JNDI tree - maybe "java:jboss/shared", maybe something else
> * Server-side services would opt-in to Remote JNDI; initially we'd only support:
> ** Remote EJB interfaces
> ** HornetQ connection factories
> * In the future we may support:
> ** User bindings, so long as they're serializable
> * In the future we will never support:
> ** Proxied DataSources
> ** Proxied JMS invocations
> Initial project tree is at https://github.com/dmlloyd/jboss-remote-jndi for now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-1338) Remote JNDI support for AS7
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/AS7-1338?page=com.atlassian.jira.plugin.s... ]
Jason Greene commented on AS7-1338:
-----------------------------------
The problem is that we currently create a connection per InitialContext, and you need to close() it so the connection gets cleaned up, else gc is abruptly closing the socket. So try adding a close() call in your try statement. We are looking at a change to reuse connections which will prevent piling them up.
> Remote JNDI support for AS7
> ---------------------------
>
> Key: AS7-1338
> URL: https://issues.jboss.org/browse/AS7-1338
> Project: Application Server 7
> Issue Type: Task
> Components: Naming
> Reporter: Richard Opalka
> Assignee: John Bailey
> Priority: Critical
> Labels: eap6_prd_req
> Fix For: 7.1.0.Final
>
>
> Add support for remote JNDI after all. It was agreed that:
> * Remote JNDI would run over Remoting
> * Remote JNDI for EJB is strictly a legacy access protocol, deprecated in favor of "ejb:"
> * The Remote JNDI service would proxy to a specific Context of the server JNDI tree - maybe "java:jboss/shared", maybe something else
> * Server-side services would opt-in to Remote JNDI; initially we'd only support:
> ** Remote EJB interfaces
> ** HornetQ connection factories
> * In the future we may support:
> ** User bindings, so long as they're serializable
> * In the future we will never support:
> ** Proxied DataSources
> ** Proxied JMS invocations
> Initial project tree is at https://github.com/dmlloyd/jboss-remote-jndi for now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-3031) NullPointerException in jboss.jacorb.poa-service.rootpoa on clean shutdown
by Radoslav Husar (Created) (JIRA)
NullPointerException in jboss.jacorb.poa-service.rootpoa on clean shutdown
--------------------------------------------------------------------------
Key: AS7-3031
URL: https://issues.jboss.org/browse/AS7-3031
Project: Application Server 7
Issue Type: Bug
Components: MSC
Affects Versions: No Release
Environment: todays master 49c6d332bc239e63671802647d7aa3aa54879fa1
Reporter: Radoslav Husar
Assignee: David Lloyd
Fix For: 7.1.0.Final
Just noticed now.
(The web NPE is reported here AS7-2877, connectors dont wait but they should).
{noformat}
[JBossINF] 19:15:54,401 INFO [org.jboss.as.messaging] (MSC service thread 1-14) JBAS011605: Unbound messaging object to jndi name java:/RemoteConnectionFactory
[JBossINF] 19:15:54,401 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-11) Pausing Coyote HTTP/1.1 on http-perf18-10.16.90.54-8080
[JBossINF] 19:15:54,402 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-11) Stopping Coyote HTTP/1.1 on http-perf18-10.16.90.54-8080
[JBossINF] 19:15:54,404 INFO [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-6) ISPN000029: Passivating all entries to disk
[JBossINF] 19:15:54,405 INFO [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-6) ISPN000030: Passivated 0 entries in 1 milliseconds
2011/12/14 19:15:54:413 EST [DEBUG][RMI TCP Connection(11)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - JBossShutdown command executed successfuly.
2011/12/14 19:15:54:414 EST [DEBUG][RMI TCP Connection(11)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Waiting for server to shutdown.
[JBossINF] 19:15:54,418 INFO [org.jboss.as.logging] JBAS011503: Restored bootstrap log handlers
[JBossINF] 19:15:54,424 INFO [org.jboss.as.osgi] JBAS011921: Stopping OSGi Framework
[JBossINF] 19:15:54,427 WARN [org.jboss.msc.service.fail] MSC00004: Failure during stop of service jboss.jacorb.poa-service.rootpoa: java.lang.NullPointerException
[JBossINF] at org.jacorb.poa.POA.destroy(Unknown Source)
[JBossINF] at org.jboss.as.jacorb.service.CorbaPOAService.stop(CorbaPOAService.java:187)
[JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1909) [jboss-msc-1.0.1.GA.jar:]
[JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1872) [jboss-msc-1.0.1.GA.jar:]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
[JBossINF]
[JBossINF] 19:15:54,440 INFO [org.jboss.as.clustering] JBAS010302: Stopped org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl cache from sfsb container
[JBossINF] 19:15:54,446 INFO [org.jboss.as.connector.subsystems.datasources] JBAS010409: Unbound data source [java:jboss/datasources/ExampleDS]
[JBossINF] 19:15:54,451 INFO [org.apache.coyote.ajp.AjpProtocol] Pausing Coyote AJP/1.3 on ajp-perf18-10.16.90.54-8009
[JBossINF] 19:15:54,451 INFO [org.apache.coyote.ajp.AjpProtocol] Stopping Coyote AJP/1.3 on ajp-perf18-10.16.90.54-8009
[JBossINF] 19:15:54,453 INFO [org.apache.catalina.core.StandardContext] Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started
[JBossINF] 19:15:54,454 INFO [org.jboss.as.clustering] JBAS010302: Stopped org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB cache from sfsb container
[JBossINF] 19:15:54,461 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000029: Passivating all entries to disk
[JBossINF] 19:15:54,464 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000029: Passivating all entries to disk
[JBossINF] 19:15:54,465 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000030: Passivated 0 entries in 1 milliseconds
[JBossINF] 19:15:54,465 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000030: Passivated 0 entries in 4 milliseconds
[JBossINF] 19:15:54,470 INFO [org.hornetq.core.server.impl.HornetQServerImpl] HornetQ Server version 2.2.7.Final (HQ_2_2_7_FINAL_AS7, 121) [a76d23d5-26b1-11e1-bff2-d48564693bb6] stopped
[JBossINF] 19:15:54,475 INFO [org.jboss.weld] Stopping weld service
[JBossINF] 19:15:54,495 INFO [org.jboss.as.clustering] JBAS010302: Stopped repl cache from sfsb container
[JBossINF] 19:15:54,495 INFO [org.jboss.as.clustering] JBAS010302: Stopped repl cache from web container
[JBossINF] 19:15:54,498 INFO [org.jboss.as.server.deployment] Stopped deployment clusterbench-ee6-ejb.jar in 53ms
[JBossINF] 19:15:54,500 INFO [org.jboss.as.server.deployment] Stopped deployment clusterbench-ee6-web.war in 55ms
[JBossINF] 19:15:54,501 INFO [org.jboss.as.server.deployment] Stopped deployment clusterbench-ee6.ear in 66ms
[JBossINF] 19:15:54,543 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000082: Stopping the RpcDispatcher
[JBossINF] 19:15:54,616 SEVERE [org.jgroups.protocols.UNICAST2] perf18/web: sender window for perf19/web not found
[JBossINF] 19:15:54,631 ERROR [org.apache.catalina.connector.CoyoteAdapter] An exception or error occurred in the container during the request processing: java.lang.NullPointerException
[JBossINF] at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:524) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:359) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
[JBossINF]
[JBossINF] 19:15:54,634 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000082: Stopping the RpcDispatcher
[JBossINF] 19:15:54,635 INFO [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
[JBossINF] 19:15:54,636 INFO [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
[JBossINF] 19:15:55,003 INFO [org.jboss.as] JBoss AS 7.1.0.CR1-SNAPSHOT "Tesla" stopped in 520ms
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-3172) Logging incosistency "WARN" vs "WARNING"
by Radoslav Husar (Created) (JIRA)
Logging incosistency "WARN" vs "WARNING"
----------------------------------------
Key: AS7-3172
URL: https://issues.jboss.org/browse/AS7-3172
Project: Application Server 7
Issue Type: Bug
Components: Logging
Affects Versions: 7.1.0.CR1
Reporter: Radoslav Husar
Assignee: James Perkins
Priority: Minor
Fix For: 7.1.0.Final
AS7 internally logs as warn like this
{noformat}
12:24:10,959 WARNING [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (MSC service thread 1-11) Channel Muxer already has a default up handler installed (org.jboss.as.clustering.jgroups.ClassLoaderAwareUpHandler@f5ad7f4) but now it is being overridden
{noformat}
but projects like Infinispan end up logging
{noformat}
12:28:22,463 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] Problems unmarshalling remote command from byte buffer: org.infinispan.CacheException: Cache manager is either starting up or shutting down but it's not interrupted, so type (id=74) cannot be resolved.
{noformat}
and this is inconsistent and is a usability issue for people analying logs (like myself).
How is this handled, what can be done here?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-1338) Remote JNDI support for AS7
by Ed Keen (JIRA)
[ https://issues.jboss.org/browse/AS7-1338?page=com.atlassian.jira.plugin.s... ]
Ed Keen commented on AS7-1338:
------------------------------
Jaikiran,
I get the error message after every time I send a basic TextMessage to the queue and my MDB picks up the message and processes it. I am seeing this on Windows XP Professional, which is our local development environment. It does not appear that the log messages are affecting functionality, because the message is picked up and processed. However, if this happens in our live environment, we might have a problem with so many ERROR level log entries.
Here is my sample code:
{code}
Session session = null;
Connection conn = null;
MessageProducer producer = null;
try
{
Properties props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
props.put(Context.PROVIDER_URL, "remote://localhost:4447");
Context context = new InitialContext(props);
ConnectionFactory connFactory = (ConnectionFactory) context.lookup("jms/RemoteConnectionFactory");
conn = connFactory.createConnection();
session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
Queue queue = (Queue)context.lookup(queueName);
producer = session.createProducer(queue);
Message messageToSend = session.createTextMessage("hello world");
producer.send(messageToSend);
}
catch (Exception e)
{
e.printStackTrace();
}
{code}
> Remote JNDI support for AS7
> ---------------------------
>
> Key: AS7-1338
> URL: https://issues.jboss.org/browse/AS7-1338
> Project: Application Server 7
> Issue Type: Task
> Components: Naming
> Reporter: Richard Opalka
> Assignee: John Bailey
> Priority: Critical
> Labels: eap6_prd_req
> Fix For: 7.1.0.Final
>
>
> Add support for remote JNDI after all. It was agreed that:
> * Remote JNDI would run over Remoting
> * Remote JNDI for EJB is strictly a legacy access protocol, deprecated in favor of "ejb:"
> * The Remote JNDI service would proxy to a specific Context of the server JNDI tree - maybe "java:jboss/shared", maybe something else
> * Server-side services would opt-in to Remote JNDI; initially we'd only support:
> ** Remote EJB interfaces
> ** HornetQ connection factories
> * In the future we may support:
> ** User bindings, so long as they're serializable
> * In the future we will never support:
> ** Proxied DataSources
> ** Proxied JMS invocations
> Initial project tree is at https://github.com/dmlloyd/jboss-remote-jndi for now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] Created: (AS7-1839) Console: Editing exampleDS' JNDI results in "uknown error" even tough the failure description is present on the output
by Radoslav Husar (JIRA)
Console: Editing exampleDS' JNDI results in "uknown error" even tough the failure description is present on the output
----------------------------------------------------------------------------------------------------------------------
Key: AS7-1839
URL: https://issues.jboss.org/browse/AS7-1839
Project: Application Server 7
Issue Type: Bug
Components: Console
Affects Versions: 7.0.1.Final
Reporter: Radoslav Husar
Assignee: Heiko Braun
Attachments: unknown-error-console.png
The lack of information is what I am after. I am not sure if it should work :-) (ie changing the JNDI name)
{code}
14:08:47,341 ERROR [org.jboss.as.controller] (HttpManagementService-threads - 6) Operation ("write-attribute") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "java:jboss/datasources/ExampleDS")
]) - failure description: "Attribute jndi-name is not writeable"
{code}
See screenshot.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-1338) Remote JNDI support for AS7
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/AS7-1338?page=com.atlassian.jira.plugin.s... ]
jaikiran pai commented on AS7-1338:
-----------------------------------
Miroslav, you _don't_ need the following code block:
{code}
static {
Security.addProvider(new JBossSaslProvider());
}
{code}
The JBossSaslProvider will be picked up automatically from the client classpath as long as the JBoss SASL jar is present in the client classpath. Just make sure you have that jar and the correct version (I think 1.0.0.Beta9 is fine, but you can try 1.0.0.Final too) of that jar in the client classpath.
> Remote JNDI support for AS7
> ---------------------------
>
> Key: AS7-1338
> URL: https://issues.jboss.org/browse/AS7-1338
> Project: Application Server 7
> Issue Type: Task
> Components: Naming
> Reporter: Richard Opalka
> Assignee: John Bailey
> Priority: Critical
> Labels: eap6_prd_req
> Fix For: 7.1.0.Final
>
>
> Add support for remote JNDI after all. It was agreed that:
> * Remote JNDI would run over Remoting
> * Remote JNDI for EJB is strictly a legacy access protocol, deprecated in favor of "ejb:"
> * The Remote JNDI service would proxy to a specific Context of the server JNDI tree - maybe "java:jboss/shared", maybe something else
> * Server-side services would opt-in to Remote JNDI; initially we'd only support:
> ** Remote EJB interfaces
> ** HornetQ connection factories
> * In the future we may support:
> ** User bindings, so long as they're serializable
> * In the future we will never support:
> ** Proxied DataSources
> ** Proxied JMS invocations
> Initial project tree is at https://github.com/dmlloyd/jboss-remote-jndi for now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months