[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka updated WFLY-2426:
-------------------------------
Assignee: Ondrej Zizka
Git Pull Request: https://github.com/wildfly/wildfly/pull/5551, https://github.com/wildfly/wildfly/pull/5552
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
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
10 years, 5 months
[JBoss JIRA] (JBMETA-369) Compilation error in AbstractWebServiceRefProcessor with JDK7
by Chao Wang (JIRA)
Chao Wang created JBMETA-369:
--------------------------------
Summary: Compilation error in AbstractWebServiceRefProcessor with JDK7
Key: JBMETA-369
URL: https://issues.jboss.org/browse/JBMETA-369
Project: JBoss Metadata
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.0.6.GA
Environment: Java version: 1.7.0_40, vendor: Oracle Corporation
Reporter: Chao Wang
Assignee: Chao Wang
When I built jboss metadata on https://svn.jboss.org/repos/jbossas/projects/metadata/trunk
I received a compilation error in AbstractWebServiceRefProcessor with JDK7, but I can build without this error with JDK6.
{noformat}
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.340s
[INFO] Finished at: Mon Dec 02 17:20:37 CST 2013
[INFO] Final Memory: 13M/211M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project jboss-metadata: Compilation failure
[ERROR] /home/wangchao/work/jbossas/EAP5/metadata/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[116,28] error: incomparable types: Class<CAP#1> and Class<Object>
{noformat}
the error indicates to AbstractWebServiceRefProcessor.java:
{code:title=AbstractWebServiceRefProcessor.java|borderStyle=solid}
if(annotation.value() != Object.class && annotation.value() != Service.class)
ref.setServiceInterface(annotation.value().getName());
{code}
>From JAX-WS 2.1 to 2.2 API, the value type and default value have been changed from Object.class to Service.class.
{code:title=WebServiceRef.java|borderStyle=solid}
/**
* The service class, alwiays a type extending
* <code>javax.xml.ws.Service</code>. This element MUST be specified
* whenever the type of the reference is a service endpoint interface.
*/
// 2.1 has Class value() default Object.class;
// Fixing this raw Class type correctly in 2.2 API. This shouldn't cause
// any compatibility issues for applications.
Class<? extends Service> value() default Service.class;
{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
10 years, 5 months
[JBoss JIRA] (WFLY-409) JPA should allow for a bean validator factory per persistence unit or per application deployment
by Hardy Ferentschik (JIRA)
[ https://issues.jboss.org/browse/WFLY-409?page=com.atlassian.jira.plugin.s... ]
Hardy Ferentschik commented on WFLY-409:
----------------------------------------
{quote}
Is this to say that in applications with multiple persistence units a validator factory is created for each PU? If so, I don't think that's neccessary as I'm not aware of any PU-specific configuration related to validation.
{quote}
That's right. Maybe I am just not sure what this issue stands for.
{quote}
Instead the same VF can be used for all the PUs of one application which will save memory.
{quote}
Right
{quote}
But with WFLY-1705 done, this should actually be the case, i.e. JPA consistently uses the one and only (in the context of one application) LazyValidatorFacotry (I think that's what Scott is saying).
{quote}
If this is the case, I am fine. Then I just need to find out why my test case ( see [HV-837|https://hibernate.atlassian.net/browse/HV-837]) is not working.
> JPA should allow for a bean validator factory per persistence unit or per application deployment
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-409
> URL: https://issues.jboss.org/browse/WFLY-409
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Labels: open_to_community
> Fix For: 8.0.0.Beta1
>
>
> Currently, a new bean validator factory instance is associated with each deployed persistence unit. This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property).
> This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPARe...]).
> The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false.
> Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change.
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1751) State transfer: views installed during state transfer are never installed at the state requester
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1751?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1751 at 12/2/13 4:08 AM:
---------------------------------------------------------
SOLUTIONS:
# Ship current view with state and digest
#* This is unnecessary as the above case is an edge case and we'd ship a view that the state requester already has
# Serialize view installation and state transfer
#* Not good as joins would be delayed by ongoing state transfers (which might take a long time)
# After the state has been transferred, let the state requester ask the coordinator for the current view
#* The state requests ships its current view id
#* The coordinator checks if the view id equals the current view-id
#* If the view-ids don't match, the coordinator sends the *full view* (not delta view) to the state requester
#* Else: no-op
#* This requires 2 new messages: a GET_CURRENT_VIEW(view-id) request and a SET_CURRENT_VIEW(full-view) response
#* This could also be used when we receive a delta-view, but don't have the required view-id (investigate this later)
was (Author: belaban):
SOLUTIONS:
# Ship current view with state and digest
#* This is unnecessary as the above case is an edge case and we'd ship a view that the state requester already has
# After the state has been transferred, let the state requester ask the coordinator for the current view
#* The state requests ships its current view id
#* The coordinator checks if the view id equals the current view-id
#* If the view-ids don't match, the coordinator sends the *full view* (not delta view) to the state requester
#* Else: no-op
#* This requires 2 new messages: a GET_CURRENT_VIEW(view-id) request and a SET_CURRENT_VIEW(full-view) response
#* This could also be used when we receive a delta-view, but don't have the required view-id (investigate this later)
> State transfer: views installed during state transfer are never installed at the state requester
> ------------------------------------------------------------------------------------------------
>
> Key: JGRP-1751
> URL: https://issues.jboss.org/browse/JGRP-1751
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> If a state requester requests state and BARRIER drops all messages at the state requester, then a view V dispatched by the coordinator during the state transfer will never be installed at the state requester:
> * The current view is V1=\{A,B\}
> * B requests the state from A
> * A gets a JOIN from C
> * A mcasts the new view V2=\{A,B,C\}, seqno=6
> * A sends back a unicast state response to B including the state and a digest with A:6 (*including* V2)
> * B receives the unicast state response and installs the state and digest
> ** B's digest for A is 6
> * B receives V2 (A:6), but *drops it as message 6 is already in its digest for A !*
> --> B will never install V2 !
> This applies to all state transfer protocols which use BARRIER (STATE_TRANSFER, STATE, STATE_SOCK).
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1751) State transfer: views installed during state transfer are never installed at the state requester
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1751?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1751:
--------------------------------
SOLUTIONS:
# Ship current view with state and digest
#* This is unnecessary as the above case is an edge case and we'd ship a view that the state requester already has
# After the state has been transferred, let the state requester ask the coordinator for the current view
#* The state requests ships its current view id
#* The coordinator checks if the view id equals the current view-id
#* If the view-ids don't match, the coordinator sends the *full view* (not delta view) to the state requester
#* Else: no-op
#* This requires 2 new messages: a GET_CURRENT_VIEW(view-id) request and a SET_CURRENT_VIEW(full-view) response
#* This could also be used when we receive a delta-view, but don't have the required view-id (investigate this later)
> State transfer: views installed during state transfer are never installed at the state requester
> ------------------------------------------------------------------------------------------------
>
> Key: JGRP-1751
> URL: https://issues.jboss.org/browse/JGRP-1751
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> If a state requester requests state and BARRIER drops all messages at the state requester, then a view V dispatched by the coordinator during the state transfer will never be installed at the state requester:
> * The current view is V1=\{A,B\}
> * B requests the state from A
> * A gets a JOIN from C
> * A mcasts the new view V2=\{A,B,C\}, seqno=6
> * A sends back a unicast state response to B including the state and a digest with A:6 (*including* V2)
> * B receives the unicast state response and installs the state and digest
> ** B's digest for A is 6
> * B receives V2 (A:6), but *drops it as message 6 is already in its digest for A !*
> --> B will never install V2 !
> This applies to all state transfer protocols which use BARRIER (STATE_TRANSFER, STATE, STATE_SOCK).
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-1477) JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
by Remy Maucherat (JIRA)
[ https://issues.jboss.org/browse/WFLY-1477?page=com.atlassian.jira.plugin.... ]
Remy Maucherat commented on WFLY-1477:
--------------------------------------
It is this PR: https://github.com/jbossas/jboss-eap/pull/625
> JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1477
> URL: https://issues.jboss.org/browse/WFLY-1477
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Affects Versions: 8.0.0.Alpha1
> Environment: CentOS 6.x, JBoss AS 7.1.1.Final
> Reporter: Steve S
> Assignee: Remy Maucherat
> Labels: domain, jaas, jboss, jbossweb, login, module, security
>
> Please see the following forum post for a detailed explanation and findings(and potential workaround):
> https://community.jboss.org/message/822054#822054
> If multiple WARs are deployed that depend on a login module leveraging:
> HttpServletRequest request = (HttpServletRequest)PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> then upon undeploy of any web application in the container the HttpServletRequestPolicyContextHandler is removed(deregistered) in the stop() lifecycle method of the JBossWebRealmService, resulting in:
> 13:03:35,335 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (ajp--0.0.0.0-8009-1) Login failure: javax.security.auth.login.LoginException: java.lang.IllegalArgumentException: No PolicyContextHandler for key=javax.servlet.http.HttpServletRequest at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:117)
> for any webapps still deployed for every subsequent access to them.
> Simply redeploying any ONE of the remaining webapps or the previously undeployed webapp causes this problem to go away for all deployed applications.
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1751) State transfer: views installed during state transfer are never installed at the state requester
by Bela Ban (JIRA)
Bela Ban created JGRP-1751:
------------------------------
Summary: State transfer: views installed during state transfer are never installed at the state requester
Key: JGRP-1751
URL: https://issues.jboss.org/browse/JGRP-1751
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
If a state requester requests state and BARRIER drops all messages at the state requester, then a view V dispatcher by the coordinator during the state transfer will never be installed at the state requester:
* The current view is V1=\{A,B\}
* B requests the state from A
* A gets a JOIN from C
* A mcasts the new view V2=\{A,B,C\}, seqno=6
* A sends back a unicast state response to B including the state and a digest with A:6 (*including* V2)
* B receives the unicast state response and installs the state and digest
** B's digest for A is 6
* B receives V2 (A:6), but *drops it as message 6 is already in its digest for A !*
--> B will never install V2 !
This applies to all state transfer protocols which use BARRIER (STATE_TRANSFER, STATE, STATE_SOCK).
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1751) State transfer: views installed during state transfer are never installed at the state requester
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1751?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1751:
---------------------------
Description:
If a state requester requests state and BARRIER drops all messages at the state requester, then a view V dispatched by the coordinator during the state transfer will never be installed at the state requester:
* The current view is V1=\{A,B\}
* B requests the state from A
* A gets a JOIN from C
* A mcasts the new view V2=\{A,B,C\}, seqno=6
* A sends back a unicast state response to B including the state and a digest with A:6 (*including* V2)
* B receives the unicast state response and installs the state and digest
** B's digest for A is 6
* B receives V2 (A:6), but *drops it as message 6 is already in its digest for A !*
--> B will never install V2 !
This applies to all state transfer protocols which use BARRIER (STATE_TRANSFER, STATE, STATE_SOCK).
was:
If a state requester requests state and BARRIER drops all messages at the state requester, then a view V dispatcher by the coordinator during the state transfer will never be installed at the state requester:
* The current view is V1=\{A,B\}
* B requests the state from A
* A gets a JOIN from C
* A mcasts the new view V2=\{A,B,C\}, seqno=6
* A sends back a unicast state response to B including the state and a digest with A:6 (*including* V2)
* B receives the unicast state response and installs the state and digest
** B's digest for A is 6
* B receives V2 (A:6), but *drops it as message 6 is already in its digest for A !*
--> B will never install V2 !
This applies to all state transfer protocols which use BARRIER (STATE_TRANSFER, STATE, STATE_SOCK).
> State transfer: views installed during state transfer are never installed at the state requester
> ------------------------------------------------------------------------------------------------
>
> Key: JGRP-1751
> URL: https://issues.jboss.org/browse/JGRP-1751
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> If a state requester requests state and BARRIER drops all messages at the state requester, then a view V dispatched by the coordinator during the state transfer will never be installed at the state requester:
> * The current view is V1=\{A,B\}
> * B requests the state from A
> * A gets a JOIN from C
> * A mcasts the new view V2=\{A,B,C\}, seqno=6
> * A sends back a unicast state response to B including the state and a digest with A:6 (*including* V2)
> * B receives the unicast state response and installs the state and digest
> ** B's digest for A is 6
> * B receives V2 (A:6), but *drops it as message 6 is already in its digest for A !*
> --> B will never install V2 !
> This applies to all state transfer protocols which use BARRIER (STATE_TRANSFER, STATE, STATE_SOCK).
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-409) JPA should allow for a bean validator factory per persistence unit or per application deployment
by Gunnar Morling (JIRA)
[ https://issues.jboss.org/browse/WFLY-409?page=com.atlassian.jira.plugin.s... ]
Gunnar Morling commented on WFLY-409:
-------------------------------------
Is this to say that in applications with multiple persistence units a validator factory is created for each PU? If so, I don't think that's neccessary as I'm not aware of any PU-specific configuration related to validation. Instead the same VF can be used for all the PUs of one application which will save memory.
But with WFLY-1705 done, this should actually be the case, i.e. JPA consistently uses the one and only (in the context of one application) {{LazyValidatorFacotry}} (I think that's what Scott is saying).
> JPA should allow for a bean validator factory per persistence unit or per application deployment
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-409
> URL: https://issues.jboss.org/browse/WFLY-409
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Labels: open_to_community
> Fix For: 8.0.0.Beta1
>
>
> Currently, a new bean validator factory instance is associated with each deployed persistence unit. This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property).
> This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPARe...]).
> The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false.
> Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change.
--
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
10 years, 5 months