[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.
by shinzey shinzey (JIRA)
shinzey shinzey created WFLY-3189:
-------------------------------------
Summary: Error validating jboss-ejb3.xml.
Key: WFLY-3189
URL: https://issues.jboss.org/browse/WFLY-3189
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB
Affects Versions: 8.0.0.Final
Environment: WildFly 8.0.0.Final
Reporter: shinzey shinzey
Assignee: David Lloyd
I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error:
{noformat}
src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33]
src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35]
src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37]
src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35]
src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39]
{noformat}
The jboss-ejb3.xml is quite simple:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss:ejb-jar version="3.1" impl-version="2.0"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
xmlns:s="urn:security:1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd">
<assembly-descriptor>
<s:security>
<ejb-name>*</ejb-name>
<s:security-domain>testsd</s:security-domain>
</s:security>
</assembly-descriptor>
</jboss:ejb-jar>
{code}
--
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
12 years, 1 month
[JBoss JIRA] (DROOLS-424) drools-camel support for session-scoped knowledge session
by Damon Horrell (JIRA)
[ https://issues.jboss.org/browse/DROOLS-424?page=com.atlassian.jira.plugin... ]
Damon Horrell commented on DROOLS-424:
--------------------------------------
If anyone is looking for a server for drools with a session-scoped knowledge session then you can use:
http://anonsvn.jboss.org/repos/tohu/trunk/tohu/tohu-xml/src/main/java/org...
This is part of the Tohu project but there is nothing Tohu-specific about it so it could be easily adapted for other purposes. It uses the CommandExecutor but currently only supports request/responses in XML format.
> drools-camel support for session-scoped knowledge session
> ---------------------------------------------------------
>
> Key: DROOLS-424
> URL: https://issues.jboss.org/browse/DROOLS-424
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 5.6.0.Final
> Reporter: Damon Horrell
> Assignee: Mark Proctor
>
> The Spring configuration for drools-camel allows creation of either a stateless knowledge session (i.e. effectively request-scoped), or a single stateful knowledge session which is shared by all requests (i.e. effectively application-scoped). There is no session-scoped option.
> This differs from the earlier drools-execution-server module (version 0.0.4) which was replaced by drools-camel. drools-execution-server maintained a separate StatefulKnowledgeSession instance per HTTP session.
> Can you please add support for a session-scoped StatefulKnowledgeSession?
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3118) <vault> does not have module option
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3118?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-3118.
----------------------------
Resolution: Done
> <vault> does not have module option
> -----------------------------------
>
> Key: WFLY-3118
> URL: https://issues.jboss.org/browse/WFLY-3118
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Derek Horton
> Assignee: Kabir Khan
>
> The <vault> element in standalone/domain.xml takes a 'code' attribute specifying the class to use as the implementation. It does not let you specify a 'module' option like most similar elements have, and instead always loads the class from the org.picketbox module.
> The <vault> element should take a module option too.
> The current workaround is to add the custom vault module as a dependency in the org.picketbox module.
> Additionally, hanging any module.xml can also result in patching conflicts when customers apply future updates.
> Since we have a quite a few customers writing custom vault implementations for various pieces of functionality that it doesn't provide out of the box, we should consider making this type of customer-initiated change patch safe for customers.
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3158) @Model does not work
by Stefan Dilk (JIRA)
[ https://issues.jboss.org/browse/WFLY-3158?page=com.atlassian.jira.plugin.... ]
Stefan Dilk commented on WFLY-3158:
-----------------------------------
but in glassfish 4 this works.
i mean glassfish uses weld too, so i think it is a bug in wildfly.
please correct me if i go wrong.
> @Model does not work
> --------------------
>
> Key: WFLY-3158
> URL: https://issues.jboss.org/browse/WFLY-3158
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.Final
> Reporter: Stefan Dilk
> Assignee: Jozef Hartinger
>
> hi,
> wildfly not work with @Model annotated beans in JSF.
> @RequestScoped and @Named work.
> in this ticket it is already reported, but closed:
> https://issues.jboss.org/browse/WFLY-2372
> in the related CDI ticket the change is made, so please implement this in the next wildfly update. in glassfish4 the @Model annotation works fine.
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3136) SRV 7.7.2 non-compliance
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3136?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reopened WFLY-3136:
--------------------------------
This fix can be optimized.
> SRV 7.7.2 non-compliance
> ------------------------
>
> Key: WFLY-3136
> URL: https://issues.jboss.org/browse/WFLY-3136
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 8.0.1.Final
>
>
> From SRV 7.7.2: Distributed Environments
> Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time.
> Our default configuration for the Infinispan cache used for web sessions uses PESSIMISTIC locking. However, Infinispan only acquires locks on cache write operations. This only prevents concurrent writes to a session. Even with REPEATABLE_READ, 2 threads can read a session at the same time. We need to make sure both reads and writes to a session use cluster exclusive access, by default at least.
--
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
12 years, 1 month
[JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if TSR throws IllegalStateException
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin... ]
Jesper Pedersen updated JBJCA-1159:
-----------------------------------
Priority: Blocker (was: Critical)
> ConnectionListener leaked if TSR throws IllegalStateException
> -------------------------------------------------------------
>
> Key: JBJCA-1159
> URL: https://issues.jboss.org/browse/JBJCA-1159
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.24.Final, 1.1.4.Final
> Environment: AS7 EAP6.1
> Reporter: gui borland
> Assignee: Jesper Pedersen
> Priority: Blocker
> Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>
> When a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost.
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests.
> {code}
> ConnectionListener cl = mcp.getConnection(subject, cri);
> if (trace)
> log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
> TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
> Lock lock = getLock();
> try
> {
> lock.lockInterruptibly();
> }
> catch (InterruptedException ie)
> {
> Thread.interrupted();
> throw new ResourceException(bundle.unableObtainLock(), ie);
> }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572
--
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
12 years, 1 month
[JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if TSR throws IllegalStateException
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin... ]
Jesper Pedersen updated JBJCA-1159:
-----------------------------------
Summary: ConnectionListener leaked if TSR throws IllegalStateException (was: DB Connections leaked if TX is not active after retrieving a connection)
Fix Version/s: 1.0.25.Final
1.1.5.Final
1.2.0.Beta1
Affects Version/s: 1.1.4.Final
1.0.24.Final
(was: 1.0.19.Final)
There is a TSR.getTransactionKey() check, but that doesn't eliminate a race. So IronJacamar needs to guard against its TSR usage.
In the future, open a forum thread before creating JIRAs. Thanks
> ConnectionListener leaked if TSR throws IllegalStateException
> -------------------------------------------------------------
>
> Key: JBJCA-1159
> URL: https://issues.jboss.org/browse/JBJCA-1159
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.24.Final, 1.1.4.Final
> Environment: AS7 EAP6.1
> Reporter: gui borland
> Assignee: Jesper Pedersen
> Priority: Critical
> Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>
> When a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost.
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests.
> {code}
> ConnectionListener cl = mcp.getConnection(subject, cri);
> if (trace)
> log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
> TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
> Lock lock = getLock();
> try
> {
> lock.lockInterruptibly();
> }
> catch (InterruptedException ie)
> {
> Thread.interrupted();
> throw new ResourceException(bundle.unableObtainLock(), ie);
> }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-2689) @Producer method never called when producing a bean from a static module
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-2689?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger resolved WFLY-2689.
-----------------------------------
Fix Version/s: 8.0.0.Final
Resolution: Done
I believe this was resolved for 8.0.0.Final. Feel free to reopen if I am wrong.
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
> Key: WFLY-2689
> URL: https://issues.jboss.org/browse/WFLY-2689
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Environment: WildFly 8.0.0.CR1
> Reporter: Pedro Igor
> Assignee: Jozef Hartinger
> Fix For: 8.0.0.Final
>
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
> // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
> // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.
--
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
12 years, 1 month