[JBoss JIRA] (AS7-3198) Cannot call external OSGI bundle from EAR package - NullPointerException
by Peter Penzov (Created) (JIRA)
Cannot call external OSGI bundle from EAR package - NullPointerException
-------------------------------------------------------------------------
Key: AS7-3198
URL: https://issues.jboss.org/browse/AS7-3198
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.1.0.CR1b
Environment: Centos 5.6 JVM 1.7
Reporter: Peter Penzov
Assignee: Thomas Diesler
Priority: Blocker
I downloaded this basic example: https://github.com/bosschaert/coderthoughts/tree/master/WebAppOSGiService
I created simple EAR package with Netbeans 7.1. I configure the EAR package to call service from the OSGI bundle in the WebAppOSGiService example. I successfully compiled the sources and I uploaded them into JBoss. When I opened the web browser and type the applet into the EAR package I get this error:
Obtaining stock quote for @@@@@@@@ use proper data type! 'ACME'
java.lang.NullPointerException at org.coderthoughts.demo.web.osgi.DemoServlet.doGet(DemoServlet.java:21) at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:151) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:897) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2033) at java.lang.Thread.run(Thread.java:722)
This is the source code that I have tested
http://www.mediafire.com/?gzy43y69cga5gas
Please write me is this a bug in JBoss 7.1.0 application server or I have made a mistake.
Regards
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (AS7-672) HostController status
by Kabir Khan (Commented) (JIRA)
[ https://issues.jboss.org/browse/AS7-672?page=com.atlassian.jira.plugin.sy... ]
Kabir Khan commented on AS7-672:
--------------------------------
Is this similar to:
{code}
[standalone@localhost:9999 /] :read-resource(recursive-depth=2,include-runtime=true)
{
"outcome" => "success",
"result" => {
...
"server-state" => "running",
{code}
and
{code}
[domain@localhost:9999 /] /host=master/server=server-one:read-resource(recursive-depth=2,include-runtime=true)
{
"outcome" => "success",
"result" => {
...
"server-state" => "running",
{code}
I take it this should be per host entry, and the main aim is to check whether a slave is out of sync with the master HC?
> HostController status
> ---------------------
>
> Key: AS7-672
> URL: https://issues.jboss.org/browse/AS7-672
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Kabir Khan
> Fix For: 7.1.0.Final
>
>
> Analogous to a server's status, but for a HostController.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (JBRULES-3100) Long.MAX_VALUE duration for "A and not(B after A)" type rules causes invalid session clock time in rule RHS when running with pseudo clock
by Richard Calmbach (JIRA)
Long.MAX_VALUE duration for "A and not(B after A)" type rules causes invalid session clock time in rule RHS when running with pseudo clock
------------------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-3100
URL: https://issues.jboss.org/browse/JBRULES-3100
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core, drools-core (fusion)
Affects Versions: 5.2.0.Final
Reporter: Richard Calmbach
Assignee: Mark Proctor
Ok, this is a subtle one. How did I run into this one? I need dynamic timers that are started in the RHS because Drools LHS syntax does not support dynamic timers. In order to be able to unit test my rules even with dynamic timers, I rely on the session clock (aka TimerService) to schedule and execute these manually defined jobs. Works beautifully with the real-time clock for all my rules, and also works with the pseudo clock for rules that don't have a negated unbounded "after" clause. However, the pseudo clock breaks the timers that are scheduled in the RHS of rules that have a LHS of type "A and not(B after A)". The reason is extremely subtle, and understanding it required an excursion into the inner workings of the rule engine, in particular its mechanism for scheduling activations of rules with non-zero duration. (Good thing that javadoc and sources are now available via Maven repositories for all Drools artifacts. Thank you, Drools team and the m2eclipse "Download Artifact Sources" checkbox!)
In PseudoClockScheduler.runCallBacks(), the pseudo clock checks whether any scheduled jobs need to be executed by comparing their trigger times to the current time (this.timer). For every job that is due, e.g., a scheduled rule activation, the pseudo clock saves this.timer to a local variable (savedTimer) and sets this.timer temporarily to the trigger time of the job (keeping this.timer at that value for the duration of the job execution, e.g., the firing of the scheduled activation). Now, for rules with a bounded duration (e.g., "A and not(B after[0s, 10s] A"), this trigger time is a reasonable value (current time + duration), and everything works out. However, rules of type "A and not(B after A)" (i.e., with negated unbounded after) have a duration value of Long.MAX_VALUE. When DurationTimer.createTrigger() constructs a new PointInTimeTrigger object, it sets the trigger time to "current time + duration", and with a post-epoch current time (i.e., greater than zero) and duration == Long.MAX_VALUE, this causes wrap-around and sets the trigger time to a very large negative number. Up to this point, I think the behavior of the code is intentional (albeit hacky), to ensure that "negated unbounded after" type rules get activated right away (as they should). However, this approach has unintended, buggy consequences as we shall see. When such a scheduled rule fires, then for the duration of its RHS execution, the session clock has an invalid value (very large negative number). The only way how you would know that is if you queried the session clock, say because you're trying to schedule a dynamic timer because Drools LHS syntax only supports static timers. The upshot is that the dynamic timer job is scheduled with "very large negative number + my trigger delay" as the trigger time, which PseudoClockScheduler.runCallBacks() promptly interprets as a job that is due for execution, causing premature and therefore incorrect triggering of my dynamic timer, thereby breaking my unit tests, while the real-time clock does not exhibit this problem. And that's how I spent my Friday.
I can work around this bug by rewriting the "A and not(B after A)" construct so that I'm explicitly comparing the timestamp fields instead of using "after". However, the current Drools implementation is broken in more than one way: Say, you're simulating the events at the original Woodstock (or any other events pre-dating the Unix epoch), and you're setting the pseudo clock to a negative value so that Date.toString() gives you the actual dates of the simulated events. As long as current time is a non-positive value, adding duration == Long.MAX_VALUE will yield a time much, much later than current time. This means that "A and not(B after A)" type rules will not fire when they should because their trigger time is in a future far, far away that will never be reached during the simulation. If I interpret this correctly, this also affects rule activation with the real-time clock if it is set to a negative value (there goes your time traveler market share...).
I'm not sure what the best fix for these bugs is. A real fix probably has to rework how "negated unbounded after" type rule activations get scheduled. The duration == Long.MAX_VALUE hack isn't going to cut it. Maybe these rules don't need scheduling at all since their activations should be created right away? Anyway, tricky stuff.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (AS7-3162) RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath
by Weinan Li (Commented) (JIRA)
[ https://issues.jboss.org/browse/AS7-3162?page=com.atlassian.jira.plugin.s... ]
Weinan Li commented on AS7-3162:
--------------------------------
https://github.com/liweinan/jboss-as/commit/dcfbe826b50dd5ab35adc7b7ca6da... - anyway, the error log is improved in this situation.
> RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-3162
> URL: https://issues.jboss.org/browse/AS7-3162
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Weinan Li
> Priority: Blocker
>
> I've deployment like this:
> {code}
> @Deployment
> public static Archive<?> deploy() {
> WebArchive war = ShrinkWrap.create(WebArchive.class, "jaxrsnoap.war");
> war.addPackage(HttpRequest.class.getPackage());
> war.addClasses(ApplicationTestCase.class, ApplicationInvalid1.class);
> war.addAsWebInfResource(
> WebXml.get("<servlet-mapping>\n"
> + " <servlet-name>javax.ws.rs.core.Application</servlet-name>\n"
> + " <url-pattern>/myjaxrs/*</url-pattern>\n"
> + "</servlet-mapping>\n" + "\n"), "web.xml");
> return war;
> }
> {code}
> This deployment fails during deploying because of "Context [/jaxrsnoap] startup failed due to previous errors: java.lang.IllegalArgumentException: Servlet mapping specifies an unknown servlet name javax.ws.rs.core.Application"
> ApplicationInvalid1 is empty subclass of javax.ws.rs.core.Application like:
> {code}
> public class ApplicationInvalid1 extends Application {
> private Set<Class<?>> classes = new HashSet<Class<?>>();
> public ApplicationInvalid1() {
> }
> @Override
> public Set<Class<?>> getClasses() {
> return classes;
> }
> }
> {code}
> There isn't any reference to this class in web.xml or somewhere else. Only class is placed on classpath. If I remove this class from deployment (= change appropriate line to "war.addClasses(ApplicationTestCase.class);", everything will be OK.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (AS7-3217) Eliminate arquillian/container-managed-domain module
by Brian Stansberry (Created) (JIRA)
Eliminate arquillian/container-managed-domain module
----------------------------------------------------
Key: AS7-3217
URL: https://issues.jboss.org/browse/AS7-3217
Project: Application Server 7
Issue Type: Task
Components: Domain Management, Test Suite
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
Fix For: 7.1.0.Final
Get rid of the current arquillian/container-managed-domain module in the AS7 source tree and move the couple classes there to the testsuite/domain module. That's the only place they are used, and their current location implies they are a proper arquillian container implementation, which isn't the case. They're just some utilities that I hoped someday to turn into a proper container implementation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (AS7-3072) SecurityException deploying login quickstart on a server with signed jars
by Marek Schmidt (Created) (JIRA)
SecurityException deploying login quickstart on a server with signed jars
-------------------------------------------------------------------------
Key: AS7-3072
URL: https://issues.jboss.org/browse/AS7-3072
Project: Application Server 7
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 7.1.0.Beta1b
Reporter: Marek Schmidt
Assignee: Stuart Douglas
Priority: Blocker
Fix For: 7.1.0.Final
Attempting to deploy the "login" quickstart on AS7 with signed modules fails with the following exception:
{noformat}
17:35:11,860 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."jboss-as-login.war".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-as-login.war".WeldService: org.jboss.weld.exceptions.WeldException: by java.lang.SecurityException: class "org.jboss.as.quickstarts.login.UserManager$-2022604038$Proxy$_$$_Weld$Proxy$"'s signer information does not match signer information of other classes in the same package
at org.jboss.as.weld.services.WeldService.start(WeldService.java:96)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: org.jboss.weld.exceptions.WeldException: by java.lang.SecurityException: class "org.jboss.as.quickstarts.login.UserManager$-2022604038$Proxy$_$$_Weld$Proxy$"'s signer information does not match signer information of other classes in the same package
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:273)
at org.jboss.weld.bean.SessionBean.initProxyClass(SessionBean.java:231)
at org.jboss.weld.bean.SessionBean.initialize(SessionBean.java:164)
at org.jboss.weld.bean.AbstractProducerBean.initialize(AbstractProducerBean.java:174)
at org.jboss.weld.bean.ProducerMethod.initialize(ProducerMethod.java:115)
at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:115)
at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:204)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:344)
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81)
at org.jboss.as.weld.services.WeldService.start(WeldService.java:89)
... 5 more
Caused by: javassist.CannotCompileException: by java.lang.SecurityException: class "org.jboss.as.quickstarts.login.UserManager$-2022604038$Proxy$_$$_Weld$Proxy$"'s signer information does not match signer information of other classes in the same package
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:99)
at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:374)
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:271)
... 14 more
Caused by: java.lang.SecurityException: class "org.jboss.as.quickstarts.login.UserManager$-2022604038$Proxy$_$$_Weld$Proxy$"'s signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:807) [:1.6.0_24]
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:488) [:1.6.0_24]
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:626) [:1.6.0_24]
at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [:1.6.0_24]
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) [:1.6.0_24]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:118)
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:95)
... 16 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (JBJCA-724) Support system property to disable validation of JDBC JCA recovery connection
by Justin Bertram (Created) (JIRA)
Support system property to disable validation of JDBC JCA recovery connection
-----------------------------------------------------------------------------
Key: JBJCA-724
URL: https://issues.jboss.org/browse/JBJCA-724
Project: IronJacamar
Issue Type: Feature Request
Components: JDBC
Reporter: Justin Bertram
Assignee: Jesper Pedersen
Whenever the JBossTS transaction recovery manager asks for an XAResource from a JDBC XA datasource we call java.sql.Connection.isValid(int) to ensure the connection is valid. However, in DB2 a call to java.sql.Connection.isValid(int) causes the connection made from the DB2 JDBC driver to the back-end DB2 RDBMS to become "active" which prevents an administrative shutdown of the DB2 RDBMS instance. To deal with this quirk in the DB2 implementation of java.sql.Connection.isValid(int) and since we cannot change the configuration schema at this point we should support a new system property named "recover-connection-validation" which can be used to turn the validation off, e.g.:
-Drecover-connection-validation=false
Using "false" for "recover-connection-validation" will force the recovery connection used for an XA JDBC datasource to be re-created every time the JBossTS transaction recovery manager asks for it.
In the future we can change the configuration schema to support this functionality directly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months