[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 commented on WFLY-1406:
------------------------------------------
I just tried to replace the 4 Hibernate JARs in WildFly by Hibernate's new 4.3.0.Beta3, and the issue still exists.
> 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, 11 months
[JBoss JIRA] (JGRP-1037) Ergonomics: size thread pools dynamically
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1037?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1037:
--------------------------------
As a first stept, we're adding stats to the transport on how long it takes on average to start processing a message (or batch) [avg dead time] and how long it takes for a message to be processed, from the time the pool starts execution until the message has been processed [avg processing time]
> Ergonomics: size thread pools dynamically
> -----------------------------------------
>
> Key: JGRP-1037
> URL: https://issues.jboss.org/browse/JGRP-1037
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> Ergonomics are a step towards less configuration and more dynamic setting of values. Example: a thread pool's min and max sizes can be dynamically changed, based on observations. When we have a min size of 10, but the thread pool is always 75, then we should set the min size to 75 and possibly change the idle time too.
> This is just a first step towards ergonomics and needs to be expanded on in 3.x releases
--
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, 11 months
[JBoss JIRA] (JGRP-1037) Ergonomics: size thread pools dynamically
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1037?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1037:
--------------------------------
OK, so for the regular pool, we could use the following strategy to set the max thread pool size:
* We know the cluster size
* If we received a message from *every member at the same time*, then we'd need N threads to process those messages
* Any additional messages received from member P would get added to the table for P and then the thread would return immediately, so this is quick
* To be able to take incoming messages and place them into that table *when all threads are busy*, we should add a buffer of 1-2 threads
* So the formula for the max thread pool size of the regular pool could be CLUSTER-SIZE + 2 (to be investigated)
> Ergonomics: size thread pools dynamically
> -----------------------------------------
>
> Key: JGRP-1037
> URL: https://issues.jboss.org/browse/JGRP-1037
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> Ergonomics are a step towards less configuration and more dynamic setting of values. Example: a thread pool's min and max sizes can be dynamically changed, based on observations. When we have a min size of 10, but the thread pool is always 75, then we should set the min size to 75 and possibly change the idle time too.
> This is just a first step towards ergonomics and needs to be expanded on in 3.x releases
--
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, 11 months
[JBoss JIRA] (JGRP-1037) Ergonomics: size thread pools dynamically
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1037?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1037:
--------------------------------
Not so sure automatically adjusting the thread pool sizes makes sense:
* Even if we compute the average number of messages to be serviced by the pool, setting a large max size for the OOB pool should be enough, as the pool will increase the number of threads (the OOB has no queue by default) automatically
* For the OOB pool, if we set the max threads too high, we'd get too many threads, leading to increased context switching and contention. We'd rather lose a few requests, as this will throttle the sender because it won't get credits sent back by the receivers quickly
* For the regular pool, we have to deliver messages from a given sender P in the order in which P sent them, so setting the max thread pool size to be greater than the average number of messages in the system would be wrong, as we cannot process all regular messages right away. For example, if we have 5 messages from P, then we only need 1 thread to deliver those messages. If we had a message from P, one from Q and one from R, we'd need 3 threads. So the best way to compute the max thread pool size for regular messages is to simply set it to the current cluster size, e.g. 10 nodes == max-size of 10 (plus perhaps 1-2 spare threads). However, we also need to think about whether the queue created by default for the regular thread pool should be removed.
> Ergonomics: size thread pools dynamically
> -----------------------------------------
>
> Key: JGRP-1037
> URL: https://issues.jboss.org/browse/JGRP-1037
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> Ergonomics are a step towards less configuration and more dynamic setting of values. Example: a thread pool's min and max sizes can be dynamically changed, based on observations. When we have a min size of 10, but the thread pool is always 75, then we should set the min size to 75 and possibly change the idle time too.
> This is just a first step towards ergonomics and needs to be expanded on in 3.x releases
--
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, 11 months
[JBoss JIRA] (JBWEB-144) JSP EL ternary operator requires space before colon
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/JBWEB-144?page=com.atlassian.jira.plugin.... ]
Jean-Frederic Clere resolved JBWEB-144.
---------------------------------------
Resolution: Done
> JSP EL ternary operator requires space before colon
> ---------------------------------------------------
>
> Key: JBWEB-144
> URL: https://issues.jboss.org/browse/JBWEB-144
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat
> Affects Versions: JBossWeb-2.0.0.GA_CP09
> Reporter: Mike Millson
> Assignee: Jean-Frederic Clere
> Attachments: test.jsp
>
>
> JSP EL that worked on JBoss AS 4.0.5.GA does not work on EAP. For example, the following does not work:
> <c:set var="truevalue" value="true" />
> <c:set var="falsevalue" value="false"/>
> <c:out value="${not empty param.yes?truevalue:falsevalue}"/>
> It throws this error:
> 2009-06-11 10:40:57,487 ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /jsp/case305721.jsp(27,3) "${not empty param.yes?truevalue:falsevalue}" contains invalid expression(s): javax.el.ELException: Error Parsing: ${not empty param.yes?truevalue:falsevalue}
> at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> But this works with a space added before the colon:
> <c:out value="${not empty param.yes?truevalue :falsevalue}"/>
> This is a bug[1] that was originally fixed in Tomcat 6.0.18[2], but was subsequently found to cause a regression[3], so was re-implemented in 6.0.19.
> [1]http://issues.apache.org/bugzilla/show_bug.cgi?id=42565
> [2]http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> [3]http://issues.apache.org/bugzilla/show_bug.cgi?id=45511
--
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, 11 months
[JBoss JIRA] (JBWEB-97) Cross-context request dispatching is not working for PHP files
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/JBWEB-97?page=com.atlassian.jira.plugin.s... ]
Jean-Frederic Clere resolved JBWEB-97.
--------------------------------------
Resolution: Out of Date
> Cross-context request dispatching is not working for PHP files
> --------------------------------------------------------------
>
> Key: JBWEB-97
> URL: https://issues.jboss.org/browse/JBWEB-97
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: JBoss AS 4.2.2.GA
> Reporter: Thomas Heute
> Assignee: Jean-Frederic Clere
> Attachments: foo.zip, ScriptEnvironment.java, servlets-php.jar, servlets-php.jar
>
>
> I installed the php-examples.war from the documentation.
> Now i'm trying to do a cross-context request dispatching from a servlet in context /foo to the resource /index.php of the context /php-examples.war
> The PHP handler Servlet is lost and it ends up with: ERROR [ScriptEnvironment] Invalid script names
> It looks like the Servlet is looking in the wrong context.
> I'm attaching my test webapp which tried to include /php-examples/index.php
--
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, 11 months
[JBoss JIRA] (JBWEB-99) PHP servlet and context path
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/JBWEB-99?page=com.atlassian.jira.plugin.s... ]
Jean-Frederic Clere resolved JBWEB-99.
--------------------------------------
Resolution: Out of Date
> PHP servlet and context path
> ----------------------------
>
> Key: JBWEB-99
> URL: https://issues.jboss.org/browse/JBWEB-99
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-1.0.1.GA
> Reporter: Thomas Heute
> Assignee: Jean-Frederic Clere
> Attachments: servlets-php.jar
>
>
> By testing an existing app, i realized that $_SERVER['PHP_SELF'] was not set correctly.
> By definition: http://ch2.php.net/reserved.variables
> ===================
> 'PHP_SELF'
> The filename of the currently executing script, relative to the document root. For instance, $_SERVER['PHP_SELF'] in a script at the address http://example.com/test.php/foo.bar would be /test.php/foo.bar.
> ===================
> Unfortunately in the JBossWeb environement we have the context path in between.
> So getting that variable on http://www.example.com/myContextPath/foo/test.php returns "/foo/test.php" when it should return "/myContextPath/foo/test.php"
> In order to have existing PHP application working with no modification, $_SERVER['PHP_SELF'] should start with the context path.
> In general, other SERVER properties should be checked to see their meaning in JBossWeb.
> It would also be convenient to have access to the context path from a PHP script.
--
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, 11 months
[JBoss JIRA] (WFLY-1425) Upgrade RESTEasy from 3.0-beta-4 (April 10) to 3.0-beta-6 (May 29)
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created WFLY-1425:
----------------------------------------
Summary: Upgrade RESTEasy from 3.0-beta-4 (April 10) to 3.0-beta-6 (May 29)
Key: WFLY-1425
URL: https://issues.jboss.org/browse/WFLY-1425
Project: WildFly
Issue Type: Feature Request
Components: REST
Affects Versions: 8.0.0.Alpha1
Reporter: Juergen Zimmermann
Assignee: Stuart Douglas
Attachments: resteasy-jboss-modules-3.0-beta-6.zip
RESTEasy 3.0-beta-6 (since beta-5) provides a significant improvement:
JSON mapping can be defined via JAXB annotations instead of proprietary Jackson annotations.
I'll attach the zip file of the RESTEasy 3.0-beta-6 distribution to patch JBossAS 7.
--
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, 11 months