September 2007 - jboss-dev-forums

[Design of POJO Server] - Re: ServiceDeployer.deploy not seeing deployment errors

by adrian＠jboss.org

I've removed the spurious nulling of error in AbstractControllerContext.uninstall() I see you've already worked around the problem in system-jmx. I added an extra check to make sure the state of the ServiceContext is always FAILED when we check errors in those tests. I also reverted your change that made ServiceContext.problem private. The whole point of maintaining the ServiceContext is for backwards compatibilty where users have referenced this class (it is exposed via the ServiceController and ServiceMBeanSupport). If this field disappears it could break user code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083393#4083393 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083393

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by dimitris＠jboss.org

The java:comp environment for the standard ejb-management.jar modujle is not even accessible by the list operation on JNDIView: | Ejb 2.1 Module: "ejb-management.jar" | java:comp namespace of the MEJB bean: | Failed on lookup, javax.naming.NameNotFoundException: comp not boundjavax.naming.NameNotFoundException: comp not bound | at org.jnp.server.NamingServer.getBinding(NamingServer.java:542) | at org.jnp.server.NamingServer.getBinding(NamingServer.java:550) | at org.jnp.server.NamingServer.getObject(NamingServer.java:556) | at org.jnp.server.NamingServer.lookup(NamingServer.java:296) | at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:669) | at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629) | at org.jboss.naming.JNDIView.list(JNDIView.java:182) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) | at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) | at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258) | at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223) | at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262) | at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100) | at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82) | at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) | at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) | at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) | at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) | at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) | at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:177) | at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:105) | at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) | at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) | at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) | at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) | at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) | at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) | at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) | at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) | at java.lang.Thread.run(Thread.java:595) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083372#4083372 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083372

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: JBossAppParsingDeployer issue

by adrian＠jboss.org

"anil.saldhana(a)jboss.com" wrote : An immediate issue that I am noticing is if there exists a jboss-app.xml that defines a security domain and there is no jboss.xml in the EAR, then the ApplicationMetaData that gets generated in the process has lost the merge from the ear level settings, because the merge of the security domain is currently being done in the JBossEJBParsingDeployer. | | So no jboss.xml, implies no invocation of the JBossEJBParsingDeployer. | | So should this merging be also done in the EjbParsingDeployer? | The parsing deployers should not be doing anything except parsing (and maybe doing things like filling in the VFS url which isn't known the parser but is in the metadata). Any modification of the metadata after parsing should be in a seperate deployer. The parsing deployers aren't even guaranteed to be called if the metadata is passed in programmatically. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083353#4083353 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083353

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: ServiceDeployer.deploy not seeing deployment errors

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : The http://jira.jboss.com/jira/browse/JBAS-4684 issue is due to the ServiceDeployer.deploy method not seeing the deployment error. This is due to the AbstractController.incrementState uninstalling context with errors: | | | | ... | | finally | | { | | lockWrite(); | | if (error != null) | | { | | log.error("Error installing to " + toState.getStateString() + ": " + context.toShortString(), error); | | uninstallContext(context, ControllerState.NOT_INSTALLED, trace); | | errorContexts.put(context.getName(), context); | | context.setError(error); | | return false; | | } | | } | | | Looks to me like it is setting the error after it has done the uninstallContext() so I don't see why this wouldn't show up in the checkComplete()? NOTE: If this is the checkComplete(Deployment) rather than the full checkComplete() that does not look at the contexts created by the deployment, it is a TODO item. anonymous wrote : | The context after the ServiceDeployer.deploy calls start(context), the context is in a DESTROYED state, but has no problem set: | | | ObjectName: jboss.web.deployment:war=/custom-context | | State: DESTROYED | | | | Because of this, the MainDeployer.checkComplete call has no information about the failed deployment. | If I just fail to null out the ServiceContext.problem then the deployment failure propagates as expected. | That looks like a cut and paste error to me? i.e. uninstall() was copied from install() and the nulling of the error was not removed. We just haven't seen it before because of the setting of the error after uninstallContext() above. anonymous wrote : | However, it seem like we should not be able to transition out of the ERROR state to DESTROYED? | That is only on the old ServiceContext (which isn't used for the checkComplete()) It is not being maintained properly because the setError() hasn't been invoked yet. The real ServiceControllerContext should be in the ERROR state? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083351#4083351 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083351

17 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: Maven Migration Status

by thomas.heute＠jboss.com

By the way, doesn't maven have a implode feature that would make our implode ant task and this corresponding testcase, something from the past ? (Still needed for the parts that are not migrated to maven though) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083349#4083349 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083349

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by dimitris＠jboss.org

I had thought JBCTS-645 was causing also the appclient/assembly failures because the produced error is the same but I just tested it and don't see any improvement. Scott can you please look e.g. at com/sun/ts/tests/appclient/deploy/compat14_50/Client.java, do you want a separate JIRA case? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083347#4083347 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083347

17 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: Maven Migration Status

by julien＠jboss.com

I think we should get away from that special system property, instead put the files in the classpath and use the classloader or class object to obtain the resources we need. If we need a file instead of an URL (such as in the example), it is always possible to convert the URL to a File, as it will be an URL with the file protocol. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083332#4083332 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083332

17 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Modules depend on jboss-j2ee instead of jboss-javaee

by wolfc

Modules in jbossas trunk now have a dependency on jboss-j2ee. Should this be jboss-javaee instead? http://jira.jboss.com/jira/browse/JBBUILD-411 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083323#4083323 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083323

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Using

by aakjpe

I have a Jboss web application running on a Sun server (Soloaris). From the application I want the users to be able to download files using "Save target as..." The files are in in a directory wth name /home/mydir/files How to I refer to this files in <a href="<%= ref %>" target=_blank> I have tried wiht full path, but that does not work. Kjell P. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083309#4083309 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083309

17 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: Maven Migration Status

by thomas.heute＠jboss.com

I would do both :) If the system property is not set defaults to : path + "/target/test-classes/implode/foo.sar" I don't know Maven to propose a 3rd solution but it looked like you already know the workarounds. Does the maven build changes the structure of the files we have in the common modules ? If yes, what's the new structure ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083304#4083304 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083304

17 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2007