[JBoss JIRA] (WFCORE-543) Revisit how the model validation happens
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-543?page=com.atlassian.jira.plugin... ]
Kabir Khan moved WFLY-4346 to WFCORE-543:
-----------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-543 (was: WFLY-4346)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Alpha18
(was: 9.0.0.Beta1)
> Revisit how the model validation happens
> ----------------------------------------
>
> Key: WFCORE-543
> URL: https://issues.jboss.org/browse/WFCORE-543
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha18
>
>
> Currently the ValidateModelStepHandler is triggered by AbstractAddStepHandler. Not all add handlers extend AbstractAddStepHandler. Also, it does not seem to be triggered for writes.
> Also if used in a composite along the lines of
> {code}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] /system-property=xxx:add(value=test)
> [standalone@localhost:9990 / #] /system-property=xxx:remove
> [standalone@localhost:9990 / #] run-batch
> {code}
> the handler will get triggered at the end for the add. It will fail for the add since there is no such resource. While that is easy to work around by checking for a NoSuchResourceException around the OC.readResource() it seems that what triggers the use of the ValidateModelStepHandler should be more an intrinsic part of the controller which knows what has and has not been added/removed/written to.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4346) Revisit how the model validation happens
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4346?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4346:
-----------------------------
Description:
Currently the ValidateModelStepHandler is triggered by AbstractAddStepHandler. Not all add handlers extend AbstractAddStepHandler. Also, it does not seem to be triggered for writes.
Also if used in a composite along the lines of
{code}
[standalone@localhost:9990 /] batch
[standalone@localhost:9990 / #] /system-property=xxx:add(value=test)
[standalone@localhost:9990 / #] /system-property=xxx:remove
[standalone@localhost:9990 / #] run-batch
{code}
the handler will get triggered at the end for the add. It will fail for the add since there is no such resource. While that is easy to work around by checking for a NoSuchResourceException around the OC.readResource() it seems that what triggers the use of the ValidateModelStepHandler should be more an intrinsic part of the controller which knows what has and has not been added/removed/written to.
was:
Currently the ValidateModelStepHandler is triggered by AbstractAddStepHandler, and does not seem to be triggered for writes.
Also if used in a composite along the lines of
{code}
[standalone@localhost:9990 /] batch
[standalone@localhost:9990 / #] /system-property=xxx:add(value=test)
[standalone@localhost:9990 / #] /system-property=xxx:remove
[standalone@localhost:9990 / #] run-batch
{code}
the handler will get triggered at the end for the add. It will fail for the add since there is no such resource. While that is easy to work around by checking for a NoSuchResourceException around the OC.readResource() it seems that what triggers the use of the ValidateModelStepHandler should be more an intrinsic part of the controller which knows what has and has not been added/removed/written to.
> Revisit how the model validation happens
> ----------------------------------------
>
> Key: WFLY-4346
> URL: https://issues.jboss.org/browse/WFLY-4346
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Fix For: 9.0.0.Beta1
>
>
> Currently the ValidateModelStepHandler is triggered by AbstractAddStepHandler. Not all add handlers extend AbstractAddStepHandler. Also, it does not seem to be triggered for writes.
> Also if used in a composite along the lines of
> {code}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] /system-property=xxx:add(value=test)
> [standalone@localhost:9990 / #] /system-property=xxx:remove
> [standalone@localhost:9990 / #] run-batch
> {code}
> the handler will get triggered at the end for the add. It will fail for the add since there is no such resource. While that is easy to work around by checking for a NoSuchResourceException around the OC.readResource() it seems that what triggers the use of the ValidateModelStepHandler should be more an intrinsic part of the controller which knows what has and has not been added/removed/written to.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4346) Revisit how the model validation happens
by Kabir Khan (JIRA)
Kabir Khan created WFLY-4346:
--------------------------------
Summary: Revisit how the model validation happens
Key: WFLY-4346
URL: https://issues.jboss.org/browse/WFLY-4346
Project: WildFly
Issue Type: Feature Request
Components: Domain Management
Reporter: Kabir Khan
Assignee: Brian Stansberry
Fix For: 9.0.0.Beta1
Currently the ValidateModelStepHandler is triggered by AbstractAddStepHandler, and does not seem to be triggered for writes.
Also if used in a composite along the lines of
{code}
[standalone@localhost:9990 /] batch
[standalone@localhost:9990 / #] /system-property=xxx:add(value=test)
[standalone@localhost:9990 / #] /system-property=xxx:remove
[standalone@localhost:9990 / #] run-batch
{code}
the handler will get triggered at the end for the add. It will fail for the add since there is no such resource. While that is easy to work around by checking for a NoSuchResourceException around the OC.readResource() it seems that what triggers the use of the ValidateModelStepHandler should be more an intrinsic part of the controller which knows what has and has not been added/removed/written to.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4345) ServiceNotFoundException for EJB referencing another EJB
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-4345:
---------------------------------
Summary: ServiceNotFoundException for EJB referencing another EJB
Key: WFLY-4345
URL: https://issues.jboss.org/browse/WFLY-4345
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Reporter: Jeff Mesnil
Assignee: Stuart Douglas
I have an test with a client that uses two EJBs
{noformat}
class Client {
@EJB(name="ejb/CDIUseCasesCMBEAN1")
static CMBean1IF cmbean1;
@EJB(name="ejb/CDIUseCasesCMBEAN2")
static CMBean2IF cmbean2;
}
{noformat}
The first EJB also references the second EJB:
{noformat}
@Stateless(name="CDIUseCasesCMBEAN1")
@Remote({CMBean1IF.class})
public class CMBean1 implements CMBean1IF {
@EJB(name="ejb/CDIUseCasesCMBEAN2")
CMBean2IF cmbean2;
}
@TransactionManagement(TransactionManagementType.CONTAINER)
@Stateless(name="CDIUseCasesCMBEAN2")
@Remote({CMBean2IF.class})
public class CMBean2 implements CMBean2IF {
}
{noformat}
When I deploy my application, the deployment fails with the error:
{noformat}
[javatest.batch] 11:39:17,668 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."cditestsusecases.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."cditestsusecases.ear".WeldStartService: Failed to start service
[javatest.batch] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.4.Final.jar:1.2.4.Final]
[javatest.batch] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
[javatest.batch] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
[javatest.batch] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
[javatest.batch] Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.deployment.subunit."cditestsusecases.ear"."cditestsusecases_ejb.jar".component.CDIUseCasesCMBEAN2.VIEW."com.sun.ts.tests.jms.ee20.cditests.usecases.CMBean2IF".REMOTE not found
[javatest.batch] at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:669) [jboss-msc-1.2.4.Final.jar:1.2.4.Final]
[javatest.batch] at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices.getComponentView(WeldEjbInjectionServices.java:149)
[javatest.batch] at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices.handleServiceLookup(WeldEjbInjectionServices.java:124)
[javatest.batch] at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices.registerEjbInjectionPoint(WeldEjbInjectionServices.java:106)
{noformat}
As far as I can tell, the application is correctly built.
The client jar contains the Client classes and the beans remote interfaces.
The EJB jar contains the bean remote interfaces and classes.
I debugged WildFly and fixed the issue by updating org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices#getComponentView to take into account that the EJB's view service may not be UP yet when the CMBean2IF EJB is injected into CMBean1.cmbean2 field:
{noformat}
private ComponentView getComponentView(ViewDescription viewDescription) {
final ServiceController<?> controller = serviceRegistry.getService(viewDescription.getServiceName());
if (controller == null) {
return null;
}
return (ComponentView) controller.getValue();
}
{noformat}
If there is no component view, the WeldEjbInjectionServices#handleServiceLookup will instead use a lazy resource.
After that changes, my test passes fine.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-81) Expose address of DC as runtime attributes on the HC
by Thomas Segismont (JIRA)
[ https://issues.jboss.org/browse/WFCORE-81?page=com.atlassian.jira.plugin.... ]
Thomas Segismont commented on WFCORE-81:
----------------------------------------
Reminder (as requested by [~ehugonnet]): RHQ is only able to talk to a HC/DC over an HTTP management connection
[~pilhuhn] We're trying to figure out which problem needs to be solved. Can you provide more context? Is there any RHQ bug or feature request related to this issue?
> Expose address of DC as runtime attributes on the HC
> ----------------------------------------------------
>
> Key: WFCORE-81
> URL: https://issues.jboss.org/browse/WFCORE-81
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Rupp
> Assignee: Emmanuel Hugonnet
> Labels: rhq
>
> Currently there is no way to learn about the http management port of the DC from a slave's host.xml or runtime.
> 17:02:31] <pilhuhn> I am reading host.xml to find the DC, so that I can contact its http port for e.g. querying the /socket-binding-group if the one on the host is undefined
> [17:02:41] <+bstansberry> I don't want it in the config, but I'm ok with adding it as a runtime attribute
> [17:04:13] <pilhuhn> bstansberry fine with me when I can query the HC for the http port of the DC
> [17:04:46] <+bstansberry> pilhuhn: the native API port should be a runtime attribute as well
> [17:04:51] <+bstansberry> yes please
> [17:05:04] <+bstansberry> what i mean by that is we should expose it as a runtime attribute
> 17:05:49] <+bstansberry> the config bit is an instruction to the HC, but we are going to add alternatives, e.g. a multicast address
> [17:06:55] <+bstansberry> so using the config will not be a reliable source; runtime can be
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-2627) EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-2627?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-2627:
-------------------------------
Fix Version/s: 8.0.0.Alpha2
> EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-2627
> URL: https://issues.jboss.org/browse/WFLY-2627
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Environment: jdk1.7.0_45_x64, Windows 7
> Reporter: Norbert Bumm
> Assignee: David Lloyd
> Fix For: 8.0.0.Alpha2
>
> Attachments: arquillian-jpa.zip, wildfly-src-7.2.0.Final-TransactionBug.patch
>
>
> If there is a global transaction declaration for “Supports” and a “Required” declaration for a specific Method the “Required” gets ignored. I first encountered the problem with an old 2.1 EJB, but the problem is also there with a 3.1 EJB with deployment descriptor. It works correct with annotations.
> ejb-jar.xml snippet
> {code:xml}
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-name>*</method-name>
> </method>
> <trans-attribute>Supports</trans-attribute>
> </container-transaction>
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>createUser</method-name>
> </method>
> <trans-attribute>Required</trans-attribute>
> </container-transaction>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-3526) Servlet 3 - async-mode - onTimeout not triggered
by Günther Grill (JIRA)
[ https://issues.jboss.org/browse/WFLY-3526?page=com.atlassian.jira.plugin.... ]
Günther Grill resolved WFLY-3526.
---------------------------------
Resolution: Done
Async Servlet works properly in 8.2.0. onTimeout is triggered.
> Servlet 3 - async-mode - onTimeout not triggered
> ------------------------------------------------
>
> Key: WFLY-3526
> URL: https://issues.jboss.org/browse/WFLY-3526
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Reporter: Günther Grill
> Assignee: Jason Greene
> Labels: async, asynchronous, servlet, timeout
> Fix For: 8.2.0.Final
>
>
> With asynchronous mode of servlets a long running process never times out.
> In my tests I have a async servlet which calls starts a long running process. That process take longer then the configured timeout. But here never a timeout comes. The long running process can complete.
> According to the spec, the servlet should run into a timeout and the AsyncListener#onTimeout method is called for registered listeners.
> But this never happens in Wildfly 8.
> Here is a test servlet
> {code:title=AsyncServlet.java|borderStyle=solid}
> @WebServlet(urlPatterns = {"/AsyncServlet"}, asyncSupported = true)
> public class AsyncServlet extends HttpServlet {
> private static final long serialVersionUID = 1L;
> public AsyncServlet() {
> super();
> }
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
> res.setContentType("text/html");
> final AsyncContext ac;
> if (req.isAsyncStarted()) {
> ac = req.getAsyncContext();
> } else {
> ac = req.startAsync();
> }
> ac.setTimeout(5000);
> ac.addListener(new AsyncListener() {
> @Override
> public void onTimeout(AsyncEvent event) throws IOException {
> System.out.println("onTimeout");
> }
> @Override
> public void onStartAsync(AsyncEvent event) throws IOException {
> System.out.println("onStartAsync");
> }
> @Override
> public void onError(AsyncEvent event) throws IOException {
> System.out.println("onError");
> }
> @Override
> public void onComplete(AsyncEvent event) throws IOException {
> // end of async processing -> end of response time
> System.out.println("onComplete");
> }
> });
> // this processor takes longer then the timeout. e.g. 20 sec
> ac.start(new Runnable() {
> @Override
> public void run() {
> try {
> Thread.sleep(20*1000); // working...
> ac.complete();
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }); // start async processing
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-3526) Servlet 3 - async-mode - onTimeout not triggered
by Günther Grill (JIRA)
[ https://issues.jboss.org/browse/WFLY-3526?page=com.atlassian.jira.plugin.... ]
Günther Grill updated WFLY-3526:
--------------------------------
Fix Version/s: 8.2.0.Final
> Servlet 3 - async-mode - onTimeout not triggered
> ------------------------------------------------
>
> Key: WFLY-3526
> URL: https://issues.jboss.org/browse/WFLY-3526
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Reporter: Günther Grill
> Assignee: Jason Greene
> Labels: async, asynchronous, servlet, timeout
> Fix For: 8.2.0.Final
>
>
> With asynchronous mode of servlets a long running process never times out.
> In my tests I have a async servlet which calls starts a long running process. That process take longer then the configured timeout. But here never a timeout comes. The long running process can complete.
> According to the spec, the servlet should run into a timeout and the AsyncListener#onTimeout method is called for registered listeners.
> But this never happens in Wildfly 8.
> Here is a test servlet
> {code:title=AsyncServlet.java|borderStyle=solid}
> @WebServlet(urlPatterns = {"/AsyncServlet"}, asyncSupported = true)
> public class AsyncServlet extends HttpServlet {
> private static final long serialVersionUID = 1L;
> public AsyncServlet() {
> super();
> }
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
> res.setContentType("text/html");
> final AsyncContext ac;
> if (req.isAsyncStarted()) {
> ac = req.getAsyncContext();
> } else {
> ac = req.startAsync();
> }
> ac.setTimeout(5000);
> ac.addListener(new AsyncListener() {
> @Override
> public void onTimeout(AsyncEvent event) throws IOException {
> System.out.println("onTimeout");
> }
> @Override
> public void onStartAsync(AsyncEvent event) throws IOException {
> System.out.println("onStartAsync");
> }
> @Override
> public void onError(AsyncEvent event) throws IOException {
> System.out.println("onError");
> }
> @Override
> public void onComplete(AsyncEvent event) throws IOException {
> // end of async processing -> end of response time
> System.out.println("onComplete");
> }
> });
> // this processor takes longer then the timeout. e.g. 20 sec
> ac.start(new Runnable() {
> @Override
> public void run() {
> try {
> Thread.sleep(20*1000); // working...
> ac.complete();
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }); // start async processing
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months