[JBoss JIRA] (WFLY-1423) Provide configurable timeout for ExternalContextObjectFactory.createContext
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-1423?page=com.atlassian.jira.plugin.... ]
Rostislav Svoboda commented on WFLY-1423:
-----------------------------------------
So when external context provider does not provide the option then the user can't set anything to avoid long timeouts ... which is not optimal.
Can you give us estimation how hard would it be to implement general timeout check? Thank you.
> 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
10 years, 10 months
[JBoss JIRA] (JGRP-1637) Counters overflow
by Bela Ban (JIRA)
Bela Ban created JGRP-1637:
------------------------------
Summary: Counters overflow
Key: JGRP-1637
URL: https://issues.jboss.org/browse/JGRP-1637
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.4
We have some counters which might see a lot of increments. Investigate which counters are affected (and how) by a potential wraparound, e.g. longs wrap around at 2^63 and go negative.
For example, storing delivery times in nanoseconds and totalling that number could end up with an overflow as e.g. 2ms = 2000000ns, for 1 million msgs/sec would overflow in roughly 7 weeks ! That's the reason org.jgroups.util.Average was created: instead of totalling delivery time and the number of deliveries to compute avg delivery time, we only maintain a fixed array of delivery times, and its elements are randomly overwritten with new values, so we only keep the (more or less) most recent N values to compute the average.
Using a long for a message sequence number should not be an issue: even if we send 1 million messages / sec, we could send for roughly 290'000 years !
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-1406) Hibernate cannot process package-info.java any more
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1406?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann updated WFLY-1406:
-------------------------------------
Attachment: tar.log
The attached tar.log contains the output of "tar tf shop2.war"
> Hibernate cannot process package-info.java any more
> ---------------------------------------------------
>
> Key: WFLY-1406
> URL: https://issues.jboss.org/browse/WFLY-1406
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Scott Marlow
> Attachments: server.log, tar.log
>
>
> I tried the snapshot which contains Hibernate 4.3.0.Beta2. However, package-info.java files are causing problems. For instance, the package de.shop.artikelverwaltung.domain has a package-info.java which causes a NoClassDefFoundError:
> "IllegalName: de/shop/artikelverwaltung/domain.package-info". Please see the stacktrace below.
> Here is an example for package-info.java which was working with WildFly 8.0.0.Alpha1:
> @XmlAccessorType(FIELD)
> @Vetoed
> package de.shop.artikelverwaltung.domain;
> import static javax.xml.bind.annotation.XmlAccessType.FIELD;
> import javax.enterprise.inject.Vetoed;
> import javax.xml.bind.annotation.XmlAccessorType;
> The stacktrace:
> ...
> 09:29:53,880 WARN [org.jboss.modules] Failed to define class de/shop/artikelverwaltung/domain.package-info in Module "deployment.shop2.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link de/shop/artikelverwaltung/domain/package-info (Module "deployment.shop2.war:main" from Service Module Loader)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:427) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:260) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:75) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:526) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.findClass(ClassLoaderServiceImpl.java:218) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356) [rt.jar:1.7.0_21]
> at org.hibernate.annotations.common.util.ReflectHelper.classForName(ReflectHelper.java:160) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.packageForName(JavaReflectionManager.java:121) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.cfg.AnnotationBinder.bindPackage(AnnotationBinder.java:262) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.cfg.Configuration.addPackage(Configuration.java:792) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildHibernateConfiguration(EntityManagerFactoryBuilderImpl.java:1174) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:839) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:142) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:213) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$800(PersistenceUnitServiceImpl.java:58) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:107) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.lang.NoClassDefFoundError: IllegalName: de/shop/artikelverwaltung/domain.package-info
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:646) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:785) [rt.jar:1.7.0_21]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:422) [jboss-modules.jar:1.2.0.Final]
> ... 28 more
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-1424) Remote lookup for Referenceable returns Reference and not the real object
by Natasha Biryukov (JIRA)
Natasha Biryukov created WFLY-1424:
--------------------------------------
Summary: Remote lookup for Referenceable returns Reference and not the real object
Key: WFLY-1424
URL: https://issues.jboss.org/browse/WFLY-1424
Project: WildFly
Issue Type: Feature Request
Affects Versions: 8.0.0.Alpha1
Reporter: Natasha Biryukov
In JBoss EAP6.1 Alfa and Beta during remote lookup for obejct that implements Referenceable the coresponding ObjectFactory is not called, as a result the Reference object is returned and not the real one.
Code example:
public class Fruit implements Referenceable {
String fruit;
public Fruit(String f) {
fruit = f;
}
public Reference getReference() throws NamingException {
return new Reference(
Fruit.class.getName(),
new StringRefAddr("fruit", fruit),
FruitFactory.class.getName(),
null);
}
public String toString() {
return fruit;
}
}
public class FruitFactory implements ObjectFactory {
@Override
public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment) throws Exception {
Reference localObject1;
if (obj instanceof Reference) {
localObject1 = (Reference) obj;
Object fruit = localObject1.get("fruit").getContent();
return new Fruit((String)fruit);
} else {
return obj;
}
}
}
Fruit f = new Fruit("apple");
context.bind("apple", f);
Fruit f1 = (Fruit)context.lookup("apple");
--
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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months