[JBoss JIRA] (WFLY-1423) Provide configurable timeout for ExternalContextObjectFactory.createContext
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1423?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-1423.
----------------------------------
Resolution: Rejected
This is dependent upon the context. If the underlying external context provider provides the option then the user can just set the appropriate property (for LDAP I belive this is com.sun.jndi.ldap.read.timeout)
> Provide configurable timeout for ExternalContextObjectFactory.createContext
> ---------------------------------------------------------------------------
>
> Key: WFLY-1423
> URL: https://issues.jboss.org/browse/WFLY-1423
> Project: WildFly
> Issue Type: Feature Request
> Components: Naming
> Affects Versions: 8.0.0.Alpha1
> Reporter: Jan Martiska
> Assignee: Stuart Douglas
>
> An ExternalContextObjectFactory's createContext method might take a long time to complete, because usually it will communicate over the network. It would be useful to be able to cap the waiting time, and there should be a timeout enabled by default -- it might happen that the remote server will get stuck during the context creation and the external context will never be successfully created (or it will just take too much time). If a timeout occurs, createContext can for example return null, or throw an exception, not sure which is better.
--
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, 1 month
[JBoss JIRA] (WFLY-1423) Provide configurable timeout for ExternalContextObjectFactory.createContext
by Jan Martiska (JIRA)
Jan Martiska created WFLY-1423:
----------------------------------
Summary: Provide configurable timeout for ExternalContextObjectFactory.createContext
Key: WFLY-1423
URL: https://issues.jboss.org/browse/WFLY-1423
Project: WildFly
Issue Type: Feature Request
Components: Naming
Affects Versions: 8.0.0.Alpha1
Reporter: Jan Martiska
Assignee: Stuart Douglas
An ExternalContextObjectFactory's createContext method might take a long time to complete, because usually it will communicate over the network. It would be useful to be able to cap the waiting time, and there should be a timeout enabled by default -- it might happen that the remote server will get stuck during the context creation and the external context will never be successfully created (or it will just take too much time). If a timeout occurs, createContext can for example return null, or throw an exception, not sure which is better.
--
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, 1 month
[JBoss JIRA] (WFLY-762) Add schema references to standalone.xml, domain.xml, host.xml
by Prashant Srivastava (JIRA)
[ https://issues.jboss.org/browse/WFLY-762?page=com.atlassian.jira.plugin.s... ]
Prashant Srivastava commented on WFLY-762:
------------------------------------------
Thanks jai!!.Your quick response saved me alot of time.
> Add schema references to standalone.xml, domain.xml, host.xml
> -------------------------------------------------------------
>
> Key: WFLY-762
> URL: https://issues.jboss.org/browse/WFLY-762
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Gerry Matte
> Labels: domain, host, standalone, xml, xmlns
> Fix For: Awaiting Volunteers
>
>
> It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features.
> It seems quite surprising to me that these files do not have the schema references identified in the file header. Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues.
> I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users. A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on.
> Personally I favor having a switch that turns off validation - to be used on production servers only.
> If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attempted to use an out-of-date version when upgrading to a new version of JBoss AS 7.
> http://www.jboss.org/schema/jbossas/
--
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, 1 month
[JBoss JIRA] (WFLY-1421) Listing JNDI tree from container when an entry is not available causes exception
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/WFLY-1421?page=com.atlassian.jira.plugin.... ]
Jan Martiska updated WFLY-1421:
-------------------------------
Description:
When you list server's JNDI tree using management APIs and some entries cannot be retrieved, instead of these entries, it will return a marker denoting an unknown value. However, if you list the JNDI tree programatically from within the container and this happens, you get a NamingException. I believe that the listBindings operation should also return a marker for an unknown value (like null), rather than failing the whole operation.
How to reproduce:
Bind a federated JNDI context, like so:
{noformat}
/subsystem=naming/binding=java\:global\/tt:add(binding-type=external-context, module=org.jboss.as.naming, class=javax.naming.directory.InitialDirContext, environment={["java.naming.provider.url"=>"ldap://some.ldap.url:389", "java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory", "initial-context-class"=>"javax.naming.directory.InitialDirContext"]}, cache=false)
{noformat}
then, at some point in time, make this context become unavailable, for example stop the backing LDAP server (or block the connection to it using a firewall..).
*Other option* - as a simpler reproducer, you may just add any invalid URL in the java.naming.provider.url property, then it will fail always.
After that, do this in a deployed application:
{noformat}
InitialContext ctx = new InitialContext();
ctx.listBindings("java:global");
{noformat}
it will throw a NamingException after the connection attempt times out.
{noformat}
javax.naming.NamingException: java.lang.reflect.InvocationTargetException [Root exception is java.lang.RuntimeException: java.lang.reflect.InvocationTargetException]
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142)
at org.jboss.as.naming.ServiceBasedNamingStore.listBindings(ServiceBasedNamingStore.java:216)
at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:347)
at org.jboss.as.naming.InitialContext.listBindings(InitialContext.java:131)
at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:363)
at javax.naming.InitialContext.listBindings(InitialContext.java:466) [rt.jar:1.7.0_21]
at ListingServlet.doGet(ListingServlet.java:30) ... 33 more
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:258)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
... 39 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_21]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_21]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_21]
at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_21]
at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:52)
at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
... 40 more
Caused by: javax.naming.CommunicationException: ldap.cz:3890 [Root exception is java.net.ConnectException: Connection timed out]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:224) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1600) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_21]
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_21]
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_21]
at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_21]
at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_21]
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) [rt.jar:1.7.0_21]
... 47 more
Caused by: java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_21]
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_21]
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_21]
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_21]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) [rt.jar:1.7.0_21]
at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_21]
at java.net.Socket.connect(Socket.java:528) [rt.jar:1.7.0_21]
at java.net.Socket.<init>(Socket.java:425) [rt.jar:1.7.0_21]
at java.net.Socket.<init>(Socket.java:208) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.Connection.createSocket(Connection.java:366) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:201) [rt.jar:1.7.0_21]
... 60 more
{noformat}
was:
When you list server's JNDI tree using management APIs and some entries cannot be retrieved, instead of these entries, it will return a marker denoting an unknown value. However, if you list the JNDI tree programatically from within the container and this happens, you get a NamingException. I believe that the listBindings operation should also return a marker for an unknown value (like null), rather than failing the whole operation.
How to reproduce:
Bind a federated JNDI context, like so:
{noformat}
/subsystem=naming/binding=java\:global\/tt:add(binding-type=external-context, module=org.jboss.as.naming, class=javax.naming.directory.InitialDirContext, environment={["java.naming.provider.url"=>"ldap://some.ldap.url:389", "java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory", "initial-context-class"=>"javax.naming.directory.InitialDirContext"]}, cache=false)
{noformat}
then, at some point in time, make this context become unavailable, for example stop the backing LDAP server (or block the connection to it using a firewall..).
After that, do this in a deployed application:
{noformat}
InitialContext ctx = new InitialContext();
ctx.listBindings("java:global");
{noformat}
it will throw a NamingException after the connection attempt times out.
{noformat}
javax.naming.NamingException: java.lang.reflect.InvocationTargetException [Root exception is java.lang.RuntimeException: java.lang.reflect.InvocationTargetException]
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142)
at org.jboss.as.naming.ServiceBasedNamingStore.listBindings(ServiceBasedNamingStore.java:216)
at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:347)
at org.jboss.as.naming.InitialContext.listBindings(InitialContext.java:131)
at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:363)
at javax.naming.InitialContext.listBindings(InitialContext.java:466) [rt.jar:1.7.0_21]
at ListingServlet.doGet(ListingServlet.java:30) ... 33 more
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:258)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
... 39 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_21]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_21]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_21]
at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_21]
at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:52)
at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
... 40 more
Caused by: javax.naming.CommunicationException: ldap.rdu.redhat.com:389 [Root exception is java.net.ConnectException: Connection timed out]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:224) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1600) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_21]
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_21]
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_21]
at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_21]
at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_21]
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) [rt.jar:1.7.0_21]
... 47 more
Caused by: java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_21]
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_21]
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_21]
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_21]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) [rt.jar:1.7.0_21]
at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_21]
at java.net.Socket.connect(Socket.java:528) [rt.jar:1.7.0_21]
at java.net.Socket.<init>(Socket.java:425) [rt.jar:1.7.0_21]
at java.net.Socket.<init>(Socket.java:208) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.Connection.createSocket(Connection.java:366) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:201) [rt.jar:1.7.0_21]
... 60 more
{noformat}
> Listing JNDI tree from container when an entry is not available causes exception
> --------------------------------------------------------------------------------
>
> Key: WFLY-1421
> URL: https://issues.jboss.org/browse/WFLY-1421
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.0.0.Alpha1
> Reporter: Jan Martiska
> Assignee: Stuart Douglas
>
> When you list server's JNDI tree using management APIs and some entries cannot be retrieved, instead of these entries, it will return a marker denoting an unknown value. However, if you list the JNDI tree programatically from within the container and this happens, you get a NamingException. I believe that the listBindings operation should also return a marker for an unknown value (like null), rather than failing the whole operation.
> How to reproduce:
> Bind a federated JNDI context, like so:
> {noformat}
> /subsystem=naming/binding=java\:global\/tt:add(binding-type=external-context, module=org.jboss.as.naming, class=javax.naming.directory.InitialDirContext, environment={["java.naming.provider.url"=>"ldap://some.ldap.url:389", "java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory", "initial-context-class"=>"javax.naming.directory.InitialDirContext"]}, cache=false)
> {noformat}
> then, at some point in time, make this context become unavailable, for example stop the backing LDAP server (or block the connection to it using a firewall..).
> *Other option* - as a simpler reproducer, you may just add any invalid URL in the java.naming.provider.url property, then it will fail always.
> After that, do this in a deployed application:
> {noformat}
> InitialContext ctx = new InitialContext();
> ctx.listBindings("java:global");
> {noformat}
> it will throw a NamingException after the connection attempt times out.
> {noformat}
> javax.naming.NamingException: java.lang.reflect.InvocationTargetException [Root exception is java.lang.RuntimeException: java.lang.reflect.InvocationTargetException]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142)
> at org.jboss.as.naming.ServiceBasedNamingStore.listBindings(ServiceBasedNamingStore.java:216)
> at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:347)
> at org.jboss.as.naming.InitialContext.listBindings(InitialContext.java:131)
> at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:363)
> at javax.naming.InitialContext.listBindings(InitialContext.java:466) [rt.jar:1.7.0_21]
> at ListingServlet.doGet(ListingServlet.java:30) ... 33 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:258)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> ... 39 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_21]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_21]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_21]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_21]
> at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
> at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:52)
> at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
> ... 40 more
> Caused by: javax.naming.CommunicationException: ldap.cz:3890 [Root exception is java.net.ConnectException: Connection timed out]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:224) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1600) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_21]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_21]
> at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) [rt.jar:1.7.0_21]
> ... 47 more
> Caused by: java.net.ConnectException: Connection timed out
> at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_21]
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) [rt.jar:1.7.0_21]
> at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_21]
> at java.net.Socket.connect(Socket.java:528) [rt.jar:1.7.0_21]
> at java.net.Socket.<init>(Socket.java:425) [rt.jar:1.7.0_21]
> at java.net.Socket.<init>(Socket.java:208) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:366) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:201) [rt.jar:1.7.0_21]
> ... 60 more
> {noformat}
--
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, 1 month
[JBoss JIRA] (WFLY-1422) allow defining infinispan caches as part of *.ear deployment
by Radai Rosenblatt (JIRA)
Radai Rosenblatt created WFLY-1422:
--------------------------------------
Summary: allow defining infinispan caches as part of *.ear deployment
Key: WFLY-1422
URL: https://issues.jboss.org/browse/WFLY-1422
Project: WildFly
Issue Type: Feature Request
Reporter: Radai Rosenblatt
right now (7.1.3) its possible to define datasources (either xml or annotation based) and jms destinations (xml) inside an *.ear deployment.
would be nice to be able to define caches, both local and clustered in a simlar (xml-based) way
--
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, 1 month
[JBoss JIRA] (WFLY-1421) Listing JNDI tree from container when an entry is not available causes exception
by Jan Martiska (JIRA)
Jan Martiska created WFLY-1421:
----------------------------------
Summary: Listing JNDI tree from container when an entry is not available causes exception
Key: WFLY-1421
URL: https://issues.jboss.org/browse/WFLY-1421
Project: WildFly
Issue Type: Bug
Components: Naming
Affects Versions: 8.0.0.Alpha1
Reporter: Jan Martiska
Assignee: Stuart Douglas
When you list server's JNDI tree using management APIs and some entries cannot be retrieved, instead of these entries, it will return a marker denoting an unknown value. However, if you list the JNDI tree programatically from within the container and this happens, you get a NamingException. I believe that the listBindings operation should also return a marker for an unknown value (like null), rather than failing the whole operation.
How to reproduce:
Bind a federated JNDI context, like so:
{noformat}
/subsystem=naming/binding=java\:global\/tt:add(binding-type=external-context, module=org.jboss.as.naming, class=javax.naming.directory.InitialDirContext, environment={["java.naming.provider.url"=>"ldap://some.ldap.url:389", "java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory", "initial-context-class"=>"javax.naming.directory.InitialDirContext"]}, cache=false)
{noformat}
then, at some point in time, make this context become unavailable, for example stop the backing LDAP server (or block the connection to it using a firewall..).
After that, do this in a deployed application:
{noformat}
InitialContext ctx = new InitialContext();
ctx.listBindings("java:global");
{noformat}
it will throw a NamingException after the connection attempt times out.
{noformat}
javax.naming.NamingException: java.lang.reflect.InvocationTargetException [Root exception is java.lang.RuntimeException: java.lang.reflect.InvocationTargetException]
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142)
at org.jboss.as.naming.ServiceBasedNamingStore.listBindings(ServiceBasedNamingStore.java:216)
at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:347)
at org.jboss.as.naming.InitialContext.listBindings(InitialContext.java:131)
at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:363)
at javax.naming.InitialContext.listBindings(InitialContext.java:466) [rt.jar:1.7.0_21]
at ListingServlet.doGet(ListingServlet.java:30) ... 33 more
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:258)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
... 39 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_21]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_21]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_21]
at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_21]
at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:52)
at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
... 40 more
Caused by: javax.naming.CommunicationException: ldap.rdu.redhat.com:389 [Root exception is java.net.ConnectException: Connection timed out]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:224) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1600) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_21]
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_21]
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_21]
at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_21]
at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_21]
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) [rt.jar:1.7.0_21]
... 47 more
Caused by: java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_21]
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_21]
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_21]
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_21]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) [rt.jar:1.7.0_21]
at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_21]
at java.net.Socket.connect(Socket.java:528) [rt.jar:1.7.0_21]
at java.net.Socket.<init>(Socket.java:425) [rt.jar:1.7.0_21]
at java.net.Socket.<init>(Socket.java:208) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.Connection.createSocket(Connection.java:366) [rt.jar:1.7.0_21]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:201) [rt.jar:1.7.0_21]
... 60 more
{noformat}
--
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, 1 month
[JBoss JIRA] (WFLY-762) Add schema references to standalone.xml, domain.xml, host.xml
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-762?page=com.atlassian.jira.plugin.s... ]
jaikiran pai commented on WFLY-762:
-----------------------------------
Each subsystem has its own set of parsers for each version of the schema. Those parsers have the knowledge of what's supported and what's not supported as elements and attributes. Note that this _isn't_ the kind of validation that I think you have in mind. These parsers *do not* read a xsd and then compare the xml. These parsers just have the knowledge of what's supposed to be there for that specific schema version. Take a look at the EJB3 subsystem 2.0 schema version parser for example https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
> Add schema references to standalone.xml, domain.xml, host.xml
> -------------------------------------------------------------
>
> Key: WFLY-762
> URL: https://issues.jboss.org/browse/WFLY-762
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Gerry Matte
> Labels: domain, host, standalone, xml, xmlns
> Fix For: Awaiting Volunteers
>
>
> It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features.
> It seems quite surprising to me that these files do not have the schema references identified in the file header. Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues.
> I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users. A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on.
> Personally I favor having a switch that turns off validation - to be used on production servers only.
> If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attempted to use an out-of-date version when upgrading to a new version of JBoss AS 7.
> http://www.jboss.org/schema/jbossas/
--
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, 1 month
[JBoss JIRA] (WFLY-762) Add schema references to standalone.xml, domain.xml, host.xml
by Prashant Srivastava (JIRA)
[ https://issues.jboss.org/browse/WFLY-762?page=com.atlassian.jira.plugin.s... ]
Prashant Srivastava commented on WFLY-762:
------------------------------------------
Hi Jason,
I read your comment that your parsing code takes care of the schema validation on boot.Can you please tell me what modules etc. from jboss souce do I have to use if I want to do some thing similar on the fly.I am generating the server standalone.xml dynamically through code and the requirement is to validate it against the whole bunch of xsds.
> Add schema references to standalone.xml, domain.xml, host.xml
> -------------------------------------------------------------
>
> Key: WFLY-762
> URL: https://issues.jboss.org/browse/WFLY-762
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Gerry Matte
> Labels: domain, host, standalone, xml, xmlns
> Fix For: Awaiting Volunteers
>
>
> It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features.
> It seems quite surprising to me that these files do not have the schema references identified in the file header. Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues.
> I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users. A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on.
> Personally I favor having a switch that turns off validation - to be used on production servers only.
> If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attempted to use an out-of-date version when upgrading to a new version of JBoss AS 7.
> http://www.jboss.org/schema/jbossas/
--
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, 1 month
[JBoss JIRA] (WFLY-1367) 4 version numbers exist for Narayana in pom.xml, despite only needing 1
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-1367?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated WFLY-1367:
--------------------------------
Description:
There are 4 different version properties for Narayana in WildFly, despite each component that uses the variable being released together (i.e. it's not possible to get a situation where the values of these versions differ).
{code} <version.org.jboss.jbossts.jbossjts>5.0.0.M2/version.org.jboss.jbossts.jbossjts>
<version.org.jboss.jbossts.jbossjts-integration>5.0.0.M2</version.org.jboss.jbossts.jbossjts-integration>
<version.org.jboss.jbossts.jbossxts>5.0.0.M2</version.org.jboss.jbossts.jbossxts>
<version.org.jboss.jbossts.narayana>5.0.0.M2</version.org.jboss.jbossts.narayana>
{code}
As well as being messy, error-prone and more effort to change; it's also caused us a merge conflict (JBTM-1691) that didn't auto-merge correctly.
One version called "version.org.jboss.narayana" would make most sense.
was:
There are 5 different version properties for Narayana in WildFly, despite each component that uses the variable being released together (i.e. it's not possible to get a situation where the values of these versions differ).
{code} <version.org.jboss.jbossts.jbossjts>5.0.0.M2/version.org.jboss.jbossts.jbossjts>
<version.org.jboss.jbossts.jbossjts-integration>5.0.0.M2</version.org.jboss.jbossts.jbossjts-integration>
<version.org.jboss.jbossts.jbossxts>5.0.0.M2</version.org.jboss.jbossts.jbossxts>
<version.org.jboss.jbossts.narayana>5.0.0.M2</version.org.jboss.jbossts.narayana>
{code}
As well as being messy, error-prone and more effort to change; it's also caused us a merge conflict (JBTM-1691) that didn't auto-merge correctly.
One version called "version.org.jboss.narayana" would make most sense.
> 4 version numbers exist for Narayana in pom.xml, despite only needing 1
> -----------------------------------------------------------------------
>
> Key: WFLY-1367
> URL: https://issues.jboss.org/browse/WFLY-1367
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Transactions
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 8.0.0.Alpha2
>
>
> There are 4 different version properties for Narayana in WildFly, despite each component that uses the variable being released together (i.e. it's not possible to get a situation where the values of these versions differ).
> {code} <version.org.jboss.jbossts.jbossjts>5.0.0.M2/version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M2</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M2</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jbossts.narayana>5.0.0.M2</version.org.jboss.jbossts.narayana>
> {code}
> As well as being messy, error-prone and more effort to change; it's also caused us a merge conflict (JBTM-1691) that didn't auto-merge correctly.
> One version called "version.org.jboss.narayana" would make most sense.
--
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, 1 month