[JBoss JIRA] (AS7-6641) Enhance XTS AS7 configuration
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/AS7-6641?page=com.atlassian.jira.plugin.s... ]
Paul Robinson moved JBTM-861 to AS7-6641:
-----------------------------------------
Project: Application Server 7 (was: JBoss Transaction Manager)
Key: AS7-6641 (was: JBTM-861)
Affects Version/s: (was: 4.15.2)
Component/s: XTS
(was: XTS)
Security: (was: Public)
> Enhance XTS AS7 configuration
> -----------------------------
>
> Key: AS7-6641
> URL: https://issues.jboss.org/browse/AS7-6641
> Project: Application Server 7
> Issue Type: Enhancement
> Components: XTS
> Reporter: Andrew Dinn
> Priority: Minor
>
> The current integration of XTS into AS7 as an AS7 extension allows optional configuration of the coordinator URL from the <xts/> element in the AS7 standalone configuration file. No other configuration options are currently supported.
> XTS ought to support more precise configuration. IN particular, it ought to be possible to enable or disable deployment of coordinator, participant or client services independently and also to choose whether to deploy WS-AT or WS-BA services or both. This requires selectively deploying only the required web service endpoints, selectively executing the required initialization routines and selectively loading the required high level service implementations and context factory implementations.
> The XTS implementation has already been factored so as to to support such discriminated bootstrapping. So this task only requires modifying the AS7 extension code to manage the relevant configuration information and install the relevant values into the XTS environment configuration beans before starting the XTS service.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (DROOLS-56) Error with Bundle activator of org.kia-api - NPE when we stop it
by Charles Moulliard (JIRA)
Charles Moulliard created DROOLS-56:
---------------------------------------
Summary: Error with Bundle activator of org.kia-api - NPE when we stop it
Key: DROOLS-56
URL: https://issues.jboss.org/browse/DROOLS-56
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Alpha1
Reporter: Charles Moulliard
Assignee: Mark Proctor
When we try to stop or update this bundle
mvn:org.kie/kie-api/6.0.0-SNAPSHOT
on Apache Karaf, the following error is generated :
ERROR: Bundle org.kie.api [74] Error stopping bundle. (java.lang.NullPointerException)
java.lang.NullPointerException
at org.kie.osgi.api.Activator.stop(Activator.java:70)
at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2361)
at org.apache.felix.framework.Felix.updateBundle(Felix.java:2095)
at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:962)
at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:949)
at org.apache.karaf.shell.osgi.UpdateBundle.doExecute(UpdateBundle.java:37)
at org.apache.karaf.shell.osgi.BundleCommand.doExecute(BundleCommand.java:42)
at org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)
at org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)
at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:474)
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:400)
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
at org.apache.karaf.shell.console.jline.Console.run(Console.java:175)
at java.lang.Thread.run(Thread.java:680)
REMARK : The package org.kie.cdi should be exported as it is used by drools-spring !!!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6614) A write-config operation
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/AS7-6614?page=com.atlassian.jira.plugin.s... ]
jaikiran pai updated AS7-6614:
------------------------------
> A write-config operation
> ------------------------
>
> Key: AS7-6614
> URL: https://issues.jboss.org/browse/AS7-6614
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
>
> Operation to force the server to write its config file, without making any actual config change.
> One use case mentioned was to get the config file updated to the latest xml namespaces following an upgrade.
> This should be trivial to implement with an operation step handler that simply does
> context.readResourceForUpdate(PathAddress.EMPT_ADDRESS);
> context.stepCompleted();
> That handler would be registered on:
> 1) The root resource for a non-managed-domain server (for standalone.xml).
> 2) The host=* resource on any HostController (for host.xml).
> 3) The root resource on a HostController that is the master (for domain.xml).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6610) Invocation access control context management
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-6610?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on AS7-6610:
----------------------------------
I implemented a special interceptor type which wraps the invocation in a provided access control context. This should form the foundation of EJB privileged invocation. It is not yet clear to me how this interrelates with JACC though.
> Invocation access control context management
> --------------------------------------------
>
> Key: AS7-6610
> URL: https://issues.jboss.org/browse/AS7-6610
> Project: Application Server 7
> Issue Type: Sub-task
> Components: Application Client, CDI / Weld, EJB, JMS, POJO, REST, Security, Web
> Reporter: David Lloyd
> Fix For: 8.0.0.Alpha1
>
>
> We need to ensure that as part of our security context propagation that we're properly handling access control contexts. For example, an async EJB invocation should have the exact same access control profile as a direct EJB invocation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months