June 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3449) Add a unit test that verifies that Hibernate ORM 4.1.x jars can be included with an application

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3449?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-3449. ------------------------------ Resolution: Done > Add a unit test that verifies that Hibernate ORM 4.1.x jars can be included with an application > ----------------------------------------------------------------------------------------------- > > Key: WFLY-3449 > URL: https://issues.jboss.org/browse/WFLY-3449 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > > Unit test should get the classloader for one of the Hibernate classes and verify that its the application classloader. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3449) Add a unit test that verifies that Hibernate ORM 4.3.5 jars can be included with an application

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3449?page=com.atlassian.jira.plugin.... ] Scott Marlow reopened WFLY-3449: -------------------------------- > Add a unit test that verifies that Hibernate ORM 4.3.5 jars can be included with an application > ----------------------------------------------------------------------------------------------- > > Key: WFLY-3449 > URL: https://issues.jboss.org/browse/WFLY-3449 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > > Unit test should get the classloader for one of the Hibernate classes and verify that its the application classloader. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3449) Add a unit test that verifies that Hibernate ORM 4.3.5 jars can be included with an application

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3449?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-3449. ------------------------------ Resolution: Done > Add a unit test that verifies that Hibernate ORM 4.3.5 jars can be included with an application > ----------------------------------------------------------------------------------------------- > > Key: WFLY-3449 > URL: https://issues.jboss.org/browse/WFLY-3449 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > > Unit test should get the classloader for one of the Hibernate classes and verify that its the application classloader. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4658) merge Jipijapa source into WildFly

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-4658?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-4658. ------------------------------ Resolution: Done > merge Jipijapa source into WildFly > ---------------------------------- > > Key: WFLY-4658 > URL: https://issues.jboss.org/browse/WFLY-4658 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 10.0.0.Alpha4 > > > Merging http://github.com/jipijapa/jipijapa sources back into WildFly to increase community involvement. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-751) Different threads accessing LeftTuple fields that reference LeftTupleSet

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-751?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-751: ------------------------------------------------ Alessandro Lazarotti <alazarot(a)redhat.com> changed the Status of [bug 1218291|https://bugzilla.redhat.com/show_bug.cgi?id=1218291] from VERIFIED to ASSIGNED > Different threads accessing LeftTuple fields that reference LeftTupleSet > ------------------------------------------------------------------------ > > Key: DROOLS-751 > URL: https://issues.jboss.org/browse/DROOLS-751 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.3.0.Beta1 > > > In class LeftTupleSetsImpl there are missing nullchecks in some methods that contains handling LeftTuple instances. I.e. in method removeInsert there is LeftTuple variable previous that is not nullchecked. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4728) Undertow no confidential port is available

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-4728?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-4728: ------------------------------- Security: (was: Security Issue) > Undertow no confidential port is available > ------------------------------------------ > > Key: WFLY-4728 > URL: https://issues.jboss.org/browse/WFLY-4728 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.CR1 > Environment: Java application server: wildfly-9.0.0.CR1 > Java Development Kit (JDK): 1.7.0_04 > OS: Windows 7 (x64) > Reporter: David Zukerman > Assignee: Stuart Douglas > Labels: security, security-constraint, undertow > > I configured my application's web.xml file to handle all calls through https: > <security-constraint> > <web-resource-collection> > <web-resource-name>All resources</web-resource-name> > <url-pattern>/*</url-pattern> > </web-resource-collection> > <user-data-constraint> > <description>SSL</description> > <transport-guarantee>CONFIDENTIAL</transport-guarantee> > </user-data-constraint> > </security-constraint> > I configured WildFly 9.0.0 CR1 to handle https request on the 443 port: > <socket-binding name="https" port="${jboss.https.port:443}"/> > <security-realm name="UndertowRealm"> > <server-identities> > <ssl> > <keystore path="keystore.jks" relative-to="jboss.server.config.dir" keystore-password="mypassword" alias="server" key-password="mypassword"/> > </ssl> > </server-identities> > </security-realm> > <https-listener name="default-https" socket-binding="https" security-realm="UndertowRealm"/> > If I type on the browser https://localhost/ca/user/1 everything is just fine, but if I type http://localhost/ca/user/1, instead of redirecting to http://localhost/ca/user/1 I get the following error: > 2015-06-03 01:49:28,228 ERROR [io.undertow.request] (default task-1) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request. > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.getRedirectURI(ServletConfidentialityConstraintHandler.java:80) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:49) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > Please note that this issue doesn't happen over WildFly 8.2 Final -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4800) No reload required when add mime-mapping to servlet-container

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4800?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-4800: --------------------------------- Assignee: Tomaz Cerar (was: Stuart Douglas) > No reload required when add mime-mapping to servlet-container > ------------------------------------------------------------- > > Key: WFLY-4800 > URL: https://issues.jboss.org/browse/WFLY-4800 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Alpha3 > Reporter: Jan Stourac > Assignee: Tomaz Cerar > Attachments: simple-web.war > > > When mime-mapping is added to servlet container then no reload of server is required, although change takes effect after server restart is performed. > Expected behaivour is either that change takes effect immediatelly after configuration is changed or that server reload is required in response message and result of the operation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-772) Change the names of capabilities added by extensions

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-772: --------------------------------------- Summary: Change the names of capabilities added by extensions Key: WFCORE-772 URL: https://issues.jboss.org/browse/WFCORE-772 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Per the discussion at http://lists.jboss.org/pipermail/wildfly-dev/2015-June/004084.html I want to remove the qualifier 'extension' from the name of capabilities provided by extensions. In the case of JMX capabilities, I plan to insert 'management' in its place; for the others I'll just drop an element of the name. The 'managment' bit will tend to group JMX stuff with other process management related capabilities org.wildfly.management.jmx org.wildfly.management.jmx.remote org.wildfly.management.http-interface org.wildfly.management.native-interface etc -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-771) Server resources off the host resource allow the removal of deployments

by luck3y (JIRA)

[ https://issues.jboss.org/browse/WFCORE-771?page=com.atlassian.jira.plugin... ] luck3y commented on WFCORE-771: ------------------------------- @BrianStansberry: This that absolutely should not work, you can't invoke config write ops on a domain server as a user. If it makes any change at all it's a bug. The way it's done is the channels used by end users, the logic there adds a header to the request, and writes are rejected based on that. > Server resources off the host resource allow the removal of deployments > ----------------------------------------------------------------------- > > Key: WFCORE-771 > URL: https://issues.jboss.org/browse/WFCORE-771 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: luck3y > > The following command succeeds, but leaves the deployment in a state that it can't be undeployed. > {code} > /host=master/server=server-two/deployment=wildfly-helloworld.war:remove > {code} > My guess is that operation should fail or further operations to remove the deployment should succeed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-771) Server resources off the host resource allow the removal of deployments

by James Perkins (JIRA)

James Perkins created WFCORE-771: ------------------------------------ Summary: Server resources off the host resource allow the removal of deployments Key: WFCORE-771 URL: https://issues.jboss.org/browse/WFCORE-771 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: James Perkins Assignee: luck3y The following command succeeds, but leaves the deployment in a state that it can't be undeployed. {code} /host=master/server=server-two/deployment=wildfly-helloworld.war:remove {code} My guess is that operation should fail or further operations to remove the deployment should succeed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2015