[JBoss JIRA] (DROOLS-514) Clean up jetty dependencies in kie-parent-with-dependencies pom.xml
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-514?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-514:
------------------------------------
Description:
1) Make an inventory (using "mvn-all dependency:tree) of all modules that use jetty dependency and clearly indicate per module:
- Jetty groupId and Jetty version
- Scope: test or production
- Build classpath: normal dependency or plugin dependency (latter makes scope n/a)
2) In theory, we should have no normal dependency in a non-test scope to Jetty, as our stuff is deployed on JBoss EAP, Tomcat, Jetty and WildFly alike. Is this true?
GWT does use Jetty, but only during compilation (= plugin classpath, not the dependencies classpath). gwt-dev is a fat jar that includes jetty even... but gwt-dev shouldn' be in the dependencies either (but it is and it needs to be removed!).
3) Based on this inventory, discuss with ge0ffrey and mantis plan of attack.
Goal: Get rid of the jetty mess in kie-parent-with-dependencies.
was:
1) Make an inventory (using "mvn-all dependency:tree) of all modules that use jetty dependency and clearly indicate:
- groupId and Jetty version
- Scope: test or production
- Build classpath: normal dependency or plugin dependency (latter makes scope n/a)
2) In theory, we should have no normal dependency in a non-test scope to Jetty, as our stuff is deployed on JBoss EAP, Tomcat, Jetty and WildFly alike. Is this true?
GWT does use Jetty, but only during compilation (= plugin classpath, not the dependencies classpath). gwt-dev is a fat jar that includes jetty even... but gwt-dev shouldn' be in the dependencies either (but it is and it needs to be removed!).
3) Based on this inventory, discuss with ge0ffrey and mantis plan of attack.
Goal: Get rid of the jetty mess in kie-parent-with-dependencies.
> Clean up jetty dependencies in kie-parent-with-dependencies pom.xml
> -------------------------------------------------------------------
>
> Key: DROOLS-514
> URL: https://issues.jboss.org/browse/DROOLS-514
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta4
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> 1) Make an inventory (using "mvn-all dependency:tree) of all modules that use jetty dependency and clearly indicate per module:
> - Jetty groupId and Jetty version
> - Scope: test or production
> - Build classpath: normal dependency or plugin dependency (latter makes scope n/a)
> 2) In theory, we should have no normal dependency in a non-test scope to Jetty, as our stuff is deployed on JBoss EAP, Tomcat, Jetty and WildFly alike. Is this true?
> GWT does use Jetty, but only during compilation (= plugin classpath, not the dependencies classpath). gwt-dev is a fat jar that includes jetty even... but gwt-dev shouldn' be in the dependencies either (but it is and it needs to be removed!).
> 3) Based on this inventory, discuss with ge0ffrey and mantis plan of attack.
> Goal: Get rid of the jetty mess in kie-parent-with-dependencies.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (DROOLS-514) Clean up jetty dependencies in kie-parent-with-dependencies pom.xml
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-514:
---------------------------------------
Summary: Clean up jetty dependencies in kie-parent-with-dependencies pom.xml
Key: DROOLS-514
URL: https://issues.jboss.org/browse/DROOLS-514
Project: Drools
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 6.1.0.Beta4
Reporter: Geoffrey De Smet
Assignee: Michael Biarnes Kiefer
1) Make an inventory (using "mvn-all dependency:tree) of all modules that use jetty dependency and clearly indicate:
- groupId and Jetty version
- Scope: test or production
- Build classpath: normal dependency or plugin dependency (latter makes scope n/a)
2) In theory, we should have no normal dependency in a non-test scope to Jetty, as our stuff is deployed on JBoss EAP, Tomcat, Jetty and WildFly alike. Is this true?
GWT does use Jetty, but only during compilation (= plugin classpath, not the dependencies classpath). gwt-dev is a fat jar that includes jetty even... but gwt-dev shouldn' be in the dependencies either (but it is and it needs to be removed!).
3) Based on this inventory, discuss with ge0ffrey and mantis plan of attack.
Goal: Get rid of the jetty mess in kie-parent-with-dependencies.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3439) Websockets not working
by Veli Cris (JIRA)
[ https://issues.jboss.org/browse/WFLY-3439?page=com.atlassian.jira.plugin.... ]
Veli Cris commented on WFLY-3439:
---------------------------------
Any news about this issue?
Do we have a sample or example for WebSockets in version 8.1.0
Thank you,
> Websockets not working
> ----------------------
>
> Key: WFLY-3439
> URL: https://issues.jboss.org/browse/WFLY-3439
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Sockets
> Affects Versions: 8.1.0.Final
> Reporter: Veli Cris
> Assignee: Stuart Douglas
>
> Hi,
> I deployed a .war file containing a single endpoint definition (Websocket). I can see following lines in console but nothing happens when trying to open connection from a websocket client. Same .war deployed in WildFly 8.0.0 is working. Please investigate!
> The configuration is standalone.
> [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener default listening on /0.0.0.0:8080
> [io.undertow.websockets.jsr] (MSC service thread 1-4) UT026003: Adding annotated server endpoint ...
> [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017534: Registered web context: ...
> [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "web.war" (runtime-name : "web.war")
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
by Andries Ehlers (JIRA)
[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ]
Andries Ehlers commented on WFLY-3386:
--------------------------------------
I'll install Wildfly 8.1.0.Final and "test" again. Unfortunately there's no clear-cut way to reproduce the problem, so I'll leave the servers for a couple of hours, redeploy, and perform the usual tasks I did in the past and see if anything pops up.
I'll feed back to you guys asap if anything pops up.
> Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3386
> URL: https://issues.jboss.org/browse/WFLY-3386
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: CentOS, Mac (Mountain Lion).
> Reporter: Andries Ehlers
> Assignee: Martin Kouba
>
> Background:
> The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI.
> Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise.
> Error:
> We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below).
> -----------------------------
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na]
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-3386:
------------------------------------
I think we should focus on the timing, i.e. when the problem occurs. "After a redeploy" and "after a few hours of inactivity" does not seem to be a coincidence. Also could you retest with WildFly 8.1.0.Final?
> Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3386
> URL: https://issues.jboss.org/browse/WFLY-3386
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: CentOS, Mac (Mountain Lion).
> Reporter: Andries Ehlers
> Assignee: Martin Kouba
>
> Background:
> The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI.
> Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise.
> Error:
> We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below).
> -----------------------------
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na]
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (SECURITY-819) LdapExt login module fetches to many attributes in RoleSearch
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-819?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-819:
--------------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1086787|https://bugzilla.redhat.com/show_bug.cgi?id=1086787] from POST to MODIFIED
> LdapExt login module fetches to many attributes in RoleSearch
> -------------------------------------------------------------
>
> Key: SECURITY-819
> URL: https://issues.jboss.org/browse/SECURITY-819
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: PicketBox_4_0_21.Beta3
> Reporter: Tom Fonteyne
> Assignee: Tom Fonteyne
>
> An LDAP server with (lets say) 1000 users in a group.
> When authentication, a query is done to retrieve the groups for the user.
> Most LDAP servers will limit the attributes send back based on authorization of the user, but can be configured to return *all* information.
> The cause is:
> / Query for roles matching the role filter
> SearchControls constraints = new SearchControls();
> constraints.setSearchScope(searchScope);
> constraints.setTimeLimit(searchTimeLimit);
> rolesSearch(ctx, constraints, username, userDN, recursion, 0);
> this used to also have:
> constraints.setReturningAttributes(new String[0]);
> at some time this was taken out.
> It needs to go back in
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month