[JBoss JIRA] (WFCORE-1493) org.jboss.as.host.controller.Main.getHostSystemProperties() doesn't propagate -Djdk.launcher.addexports.%d=%s value properly
by Richard Opalka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1493?page=com.atlassian.jira.plugi... ]
Richard Opalka updated WFCORE-1493:
-----------------------------------
Description:
JDK9 provides -XaddExports launch option to workaround potential migration problems to modularized JDK.
*When modularized JDK forks new process all -XaddExports values are translated into
-Djdk.launcher.addexports.%d=%s JVM options.*
But method org.jboss.as.host.controller.Main.getHostSystemProperties()
has problems with its values.
The format of -XaddExports (and thus for -Djdk.launcher.addexports.%d=%s too):
{noformat}
-XaddExports:<source-module>/<package>=<target-module>(,<target-module>)*{noformat}
See http://openjdk.java.net/jeps/261 for more information.
was:
JDK9 provides -XaddExports launch option to workaround potential migration problems to modularized JDK. But method org.jboss.as.host.controller.Main.getHostSystemProperties()
has problems with its values.
The format of -XaddExports is:
{noformat}-XaddExports:<source-module>/<package>=<target-module>(,<target-module>)*{noformat}
See http://openjdk.java.net/jeps/261 for more information.
Summary: org.jboss.as.host.controller.Main.getHostSystemProperties() doesn't propagate -Djdk.launcher.addexports.%d=%s value properly (was: org.jboss.as.host.controller.Main.getHostSystemProperties() doesn't propagate -XaddExports value properly)
> org.jboss.as.host.controller.Main.getHostSystemProperties() doesn't propagate -Djdk.launcher.addexports.%d=%s value properly
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1493
> URL: https://issues.jboss.org/browse/WFCORE-1493
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: Richard Opalka
> Assignee: Richard Opalka
> Fix For: 3.0.0.Alpha1
>
>
> JDK9 provides -XaddExports launch option to workaround potential migration problems to modularized JDK.
> *When modularized JDK forks new process all -XaddExports values are translated into
> -Djdk.launcher.addexports.%d=%s JVM options.*
> But method org.jboss.as.host.controller.Main.getHostSystemProperties()
> has problems with its values.
> The format of -XaddExports (and thus for -Djdk.launcher.addexports.%d=%s too):
> {noformat}
> -XaddExports:<source-module>/<package>=<target-module>(,<target-module>)*{noformat}
> See http://openjdk.java.net/jeps/261 for more information.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1492) The read-attribute result for platform mbean properties that throw UnsupportedOperationException should be 'undefined'
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1492:
----------------------------------------
Summary: The read-attribute result for platform mbean properties that throw UnsupportedOperationException should be 'undefined'
Key: WFCORE-1492
URL: https://issues.jboss.org/browse/WFCORE-1492
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Affects Versions: 2.1.0.Final
Reporter: Brian Stansberry
Fix For: 3.0.0.Beta1
Some platform mbean getters are documented to throw a UOE on some VMs. The read-resource handler will catch the UOE and leave the attribute undefined, but the read-attribute handler will convert the UOE to an OperationFailedException. This JIRA is to change that read-attribute behavior to return undefined as well.
There was a rationale for the different behavior. Basically, the read-attribute behavior is consistent with what the underlying java.lang.management.XXXMBean does -- it fails. Typically (probably always) there is another boolean getter on the mbean that will tell you if xxx is supported, with the assumption you won't call the unsupported method if not. But for read-resource, we are reading all the attributes, and we guarantee a response value. So we catch the exception and return undefined.
One minor downside to this is if JMX clients read these attributes, they'll get a null response instead of a failure. But I think that's ok; the MBeanAttributeInfo for these is created by us; these are not the real platform mbeans, they are our wrappers around them really intended for exposure over DMR, not JMX. If a JMX client wants the standard platform mbean semantics, they can access the real underlying platform mbeans.
This should be done in conjunction with WFCORE-406, which deals with ensuring our management metadata is correct.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-2634) Classloading Problem with Apache httpclient
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2634?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-2634:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1266122
Bugzilla Update: Perform
> Classloading Problem with Apache httpclient
> -------------------------------------------
>
> Key: WFLY-2634
> URL: https://issues.jboss.org/browse/WFLY-2634
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 8.0.0.Beta1
> Reporter: Ercan Oezkan
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: 8.0.0.Final
>
>
> I have a Deployment of Type WAR which includes Apache httpclient-4.3.1
> which i use to communicate to other web site for Example finance.yahoo.com.
> My Deployment includes JAX-RS Rest Services, if i deploy the WAR to JBoss-7.2.0 everything works fine. If i deploy it to Wildfly-8.0.0.Beta1 i got the following error.
> {code}
> 10:32:54,545 ERROR [org.jboss.as.ejb3] (ServerService Thread Pool -- 53) javax.ejb.EJBTransactionRolledbackException: Unexpected Error
> 10:32:54,555 ERROR [org.jboss.as.ejb3.invocation] (ServerService Thread Pool -- 53) JBAS014134: EJB Invocation failed on component TransactionEJB for method public java.lang.Object com.citc.ewallet.tx.TransactionEJB.executeWithin(com.citc.ewallet.tx.TXWork): javax.ejb.EJBTransactionRolledbackException: Unexpected Error
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:157) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> at com.citc.ewallet.tx.TransactionEJB$$$view2.executeWithin(Unknown Source) [classes:]
> at com.citc.ewallet.exchange.ExchangeService.processExchangeRates(ExchangeService.java:80) [classes:]
> at com.citc.ewallet.exchange.ExchangeService.init(ExchangeService.java:57) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_21]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_21]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_21]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_21]
> at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:165) [wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:148) [wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.0.Beta2.jar:2013-09-14 18:00]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:56) [wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:62) [wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:369) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:66) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) [wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:160)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:84)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:126) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:141) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> 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)
> Caused by: java.lang.NoSuchFieldError: INSTANCE
> at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(DefaultHttpRequestWriterFactory.java:52) [httpcore-4.3.jar:4.3]
> at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(DefaultHttpRequestWriterFactory.java:56) [httpcore-4.3.jar:4.3]
> at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<clinit>(DefaultHttpRequestWriterFactory.java:46) [httpcore-4.3.jar:4.3]
> at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>(ManagedHttpClientConnectionFactory.java:72) [httpclient-4.3.1.jar:4.3.1]
> at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>(ManagedHttpClientConnectionFactory.java:84) [httpclient-4.3.1.jar:4.3.1]
> at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<clinit>(ManagedHttpClientConnectionFactory.java:59) [httpclient-4.3.1.jar:4.3.1]
> at org.apache.http.impl.conn.PoolingHttpClientConnectionManager$InternalConnectionFactory.<init>(PoolingHttpClientConnectionManager.java:487) [httpclient-4.3.1.jar:4.3.1]
> at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:147) [httpclient-4.3.1.jar:4.3.1]
> at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:136) [httpclient-4.3.1.jar:4.3.1]
> at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:112) [httpclient-4.3.1.jar:4.3.1]
> at org.apache.http.impl.client.HttpClientBuilder.build(HttpClientBuilder.java:727) [httpclient-4.3.1.jar:4.3.1]
> at org.apache.http.impl.client.HttpClients.createDefault(HttpClients.java:58) [httpclient-4.3.1.jar:4.3.1]
> at com.citc.ewallet.exchange.ExchangeService.processRates(ExchangeService.java:105) [classes:]
> at com.citc.ewallet.exchange.ExchangeService$1.doVoidWork(ExchangeService.java:83) [classes:]
> at com.citc.ewallet.tx.TXVoidWork.doWork(TXVoidWork.java:6) [classes:]
> at com.citc.ewallet.tx.TransactionEJB.executeWithin(TransactionEJB.java:21) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_21]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_21]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_21]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_21]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:104) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.0.Beta2.jar:2013-09-14 18:00]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:52) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> ... 88 more
> {code}
> After some research i found out that JBoss-7.2.0 and Wildfly-8.0.0.Beta1 both are using httpclient-4.2.1, which are loaded through resteasy from the server modules.
> I tried to exclude the server module "org.apache.httpcomponents" with a jboss-deployment-structure.xml but got no success. It seems that something changed with the classloading of the implicit modules in Wildfly
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ELY-221) Implement a better X.500 principal mapper
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-221?page=com.atlassian.jira.plugin.sy... ]
Farah Juma reassigned ELY-221:
------------------------------
Assignee: Farah Juma
> Implement a better X.500 principal mapper
> -----------------------------------------
>
> Key: ELY-221
> URL: https://issues.jboss.org/browse/ELY-221
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: API / SPI
> Reporter: David Lloyd
> Assignee: Farah Juma
> Priority: Critical
> Fix For: 1.1.0.Beta6
>
>
> We can provide something better than a flat string mapping. Some thoughts on requirements:
> * Require that a minimum set of keys are present, else return {{null}}
> * Allow piecewise assembly of principal names with the following components:
> ** Static string
> ** Single attribute value e.g. {{dc[0]}}
> ** Joined attribute value (with optional subrange) e.g. {{dc:"."}} would convert {{dc=example,dc=com}} to {{example.com}}
> ** Joined attribute value in reverse (with optional subrange)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1129) osgi bundle have wrong metadata info
by Hiep Lq (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1129?page=com.atlassian.jira.plugi... ]
Hiep Lq commented on DROOLS-1129:
---------------------------------
yes. you are correct "It does not really matter what "X" actually is as long as we use it consistently",
"Not sure if this really matters". it's matter if you want to create a P2 repository and want to buckminter automate materialize (download) source bundle with binary bundle and automate binding it together. so helpful for debug.
i come from idempiere community. we use buckminter for setup eclipse workspace.
i just try integrate drools with idempiere. create P2 for binary is easy, but for binary + source, i have to manual modify MANIFEST.MF of source bundle
"test-jar and javadoc" P2 don't use it, so now it's ok.
> osgi bundle have wrong metadata info
> ------------------------------------
>
> Key: DROOLS-1129
> URL: https://issues.jboss.org/browse/DROOLS-1129
> Project: Drools
> Issue Type: Bug
> Components: integration
> Affects Versions: 6.4.0.Final
> Reporter: Hiep Lq
> Assignee: Petr Široký
>
> 1. bundle reteoo have wrong Bundle-SymbolicName.
> now is Bundle-SymbolicName: org.drools.core
> it should is Bundle-SymbolicName: org.drools.reteoo
> 2. base in standard of P2 repository. almost source bundle have wrong value at Bundle-SymbolicName and Eclipse-SourceBundle
> example:drools-compiler-6.4.0.Final-sources
> current value of: Bundle-SymbolicName = drools-compiler.source
> should be:Bundle-SymbolicName = org.drools.compiler.source
> current value of: Eclipse-SourceBundle=drools-compiler
> should be:Eclipse-SourceBundle=org.drools.compiler
> or we can keep source bundle, and change at binary bundle
> example change Bundle-SymbolicName of org.drools.compiler to drools-compiler
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1129) osgi bundle have wrong metadata info
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1129?page=com.atlassian.jira.plugi... ]
Petr Široký commented on DROOLS-1129:
-------------------------------------
[~hieplq] thanks, I think you answered my question. It does not really matter what "X" actually is as long as we use it consistently. As you mentioned:
- in drools-compiler-<version>.jar (the binary file), it should be {{Bundle-SymbolicName = X}}
- in drools-compiler-<version>-sources.jars (sources file), it should be {{Bundle-SymbolicName = X.source}} and {{Eclipse-SourceBundle = X}}.
Not sure if this really matters, but how should the test-jar and javadoc be named? Do they even need to be OSGi-fied (e.g. contain the metadata in MANIFEST.MF)?
> osgi bundle have wrong metadata info
> ------------------------------------
>
> Key: DROOLS-1129
> URL: https://issues.jboss.org/browse/DROOLS-1129
> Project: Drools
> Issue Type: Bug
> Components: integration
> Affects Versions: 6.4.0.Final
> Reporter: Hiep Lq
> Assignee: Petr Široký
>
> 1. bundle reteoo have wrong Bundle-SymbolicName.
> now is Bundle-SymbolicName: org.drools.core
> it should is Bundle-SymbolicName: org.drools.reteoo
> 2. base in standard of P2 repository. almost source bundle have wrong value at Bundle-SymbolicName and Eclipse-SourceBundle
> example:drools-compiler-6.4.0.Final-sources
> current value of: Bundle-SymbolicName = drools-compiler.source
> should be:Bundle-SymbolicName = org.drools.compiler.source
> current value of: Eclipse-SourceBundle=drools-compiler
> should be:Eclipse-SourceBundle=org.drools.compiler
> or we can keep source bundle, and change at binary bundle
> example change Bundle-SymbolicName of org.drools.compiler to drools-compiler
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years