You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
From: <bil...@jb...> - 2005-04-29 19:31:31
|
Also, I think a getRecoverable() may be useful in the future as well if one XAResource fails in commit we can retry it View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875975#3875975 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875975 |
From: <cle...@jb...> - 2005-04-29 18:58:08
|
At our CVS repository: http://www.jboss.org/wiki/Wiki.jsp?page=CVSRepository If you get familiar with the code, there is lots of stuff to do :-) Clebert View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875973#3875973 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875973 |
From: <aco...@jb...> - 2005-04-29 18:40:41
|
JBossIDE XML editor (latest milestone) doesn't seem to respect the settings regarding tabs and other things for the Eclipse editor. Any plans to or possibly have a property page allowing one to specify them for JBossIDE's XML editor as well? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875972#3875972 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875972 |
From: aleksvp <nu...@jb...> - 2005-04-29 18:14:01
|
Where can I get the source code of JBossProfile? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875970#3875970 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875970 |
From: <ju...@jb...> - 2005-04-29 18:03:00
|
I could not say something better View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875968#3875968 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875968 |
From: <ad...@jb...> - 2005-04-29 17:53:55
|
Another task more directly related to the subject of this thread: http://jira.jboss.com/jira/browse/JBAS-1768 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875966#3875966 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875966 |
From: mholzner <nu...@jb...> - 2005-04-29 17:52:20
|
Let me start with: whoever implemented this code and expects to be able to cast a portlet request to a http servlet request sucks as a developer ;) That out of the way: if there is enough demand for such a 'feature' it might make sense to add it, but it is fundamentally wrong, and completely against the idea of the portlet spec, so forget I even said that :) ...back to my original statement: the code sucks. You should work on the ORACLE side of the fence to fix this issue; the portal actually does the right thing. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875965#3875965 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875965 |
From: <ad...@jb...> - 2005-04-29 17:31:58
|
Having a getUnderlyingXAResource() may also be useful?? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875963#3875963 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875963 |
From: <sco...@jb...> - 2005-04-29 17:30:04
|
I guess there are many levels to this. The first is just cleaning up the existing circular dependencies, the next is cleaning up the existing hardcoded behaviors like local file system, localhost expectations with some parameterization. Beyond that are many levels of additional functionality like the remoting based extension, the multi-server based tests I created issues for: http://jira.jboss.com/jira/browse/JBAS-1487 http://jira.jboss.com/jira/browse/JBAS-1488 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875962#3875962 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875962 |
From: <ad...@jb...> - 2005-04-29 17:27:25
|
Yes, that was what we agreed. Also, getting the XAResource during recover won't go through the connection manager. Normal operation: DataSource/ConnectionFactory -> ConnectionManager -> Pool -> MCF -> ManagedConnecton -> XAResource However during recovery it doesn't use the pool/connection manager: TM -> Recoverable/MCF -> ManagedConnection -> XAResource I think you meant creating an XAResource wrapper rather than creating a proxy? :-) Make sure to delegate toString() so we don't loose the ability to see the real implementation in the logs. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875961#3875961 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875961 |
From: <aco...@jb...> - 2005-04-29 17:20:52
|
Some folks have complained that they couldn't build the dist because we removed the ant distro from the "ant" directory and they couldn't find that particular version. I should point out that any version 1.6.1+ should work. The build just is picky on the file name (we could change that but I'd rather default to known good). Heiko complained when I had ant in CVS so I removed it. Thus I have attached it to the Wiki: http://www.jboss.org/wiki/Wiki.jsp?page=MailServicesBuilding That should make everyone happier. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875960#3875960 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875960 |
From: <bil...@jb...> - 2005-04-29 17:09:10
|
This is in regards to: http://jira.jboss.com/jira/browse/JBAS-1405 I was looking on how to implement this and it seems the approach would be to create a XAResource proxy whenever the TxConnectionManager.TxConnectionEventListener.getXAResource() is called. As long as the XAResource isn't a LocalTxResource. Does this sound good? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875957#3875957 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875957 |
From: <ad...@jb...> - 2005-04-29 17:08:03
|
Its a bit confusing since there are two RARDeployment classes (one that actually is the RARDeployment, the other for the MCF - ManagedConnectionFactory). I assume you are talking about the one in org.jboss.resource.connectionmanager which is the one that turns the MCF into an MBean (by wrapping it). Yes that is the correct place. It controls the MCF "lifecycle". I believe the main change you need (beside the recovery registration) is factoring out the security subject creation that is currently in BaseConnectionManager2? OFF-TOPIC It would be better named MCFDeployment or ConnectionDefinitionDeployment. http://jira.jboss.com/jira/browse/JBAS-1425 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875956#3875956 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875956 |
From: <rya...@jb...> - 2005-04-29 17:01:26
|
I assume that part of this will be creating a JUnit runner which will start & stop a jboss instance before & after the test? The testsuite currently does this using Ant tasks to spawn the process and kill it afterwards. And I know we want the crash/reboot capability. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875955#3875955 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875955 |
From: <cle...@jb...> - 2005-04-29 16:59:46
|
oops... I forgot to mention the wiki page for this: http://www.jboss.org/wiki/Wiki.jsp?page=HowToExecuteMatrixTests View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875954#3875954 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875954 |
From: <cle...@jb...> - 2005-04-29 16:58:50
|
The code is already commited into Branch_4_0. The matrix testsuite is part of the regular testsuite. The only requirement for this is to have defined a variable -Dmatrix-versions. I'm trying to fix cruise control testsuite for jboss-4.0 and configure the matrix execution against: - jboss-4.0. (It's really broken anyway. I guess the only thing that passed was jbossMX. I will remove as soon as people are familiar with this) - jboss-4.1-sp1 - we will always check the current version just to validate classpath issues View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875953#3875953 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875953 |
From: <bil...@jb...> - 2005-04-29 16:52:32
|
This is in regards to: http://jira.jboss.com/jira/browse/JBAS-1408 After looking at the JCA code a bunch, it seems that the best place for registering the recoverable might be in the RARDeployment class? After the MCF is fully created, the Recoverable would be registered with the Recovery manager based on all the recoverable properties. Not sure this is the best place, but what I've found is that there is no Proxy in front of an MCF and that the implementation of an MCF is defined by the component plugin, correct? So it seems that RARDeployment is the best place to register the Recoverable. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875952#3875952 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875952 |
From: <jas...@jb...> - 2005-04-29 15:59:00
|
I reviewed the tests and associated schema. Everything looks good. -Jason View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875948#3875948 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875948 |
From: <tho...@jb...> - 2005-04-29 15:50:10
|
I am going to add tests for JSR-181 annotations. This will introduce a dependency on jdk5. The jboss app server (Scott) has not yet decided how to deal with functionality that has a jdk5 dependency and is targeted for jboss-4.0.x backporting. There is talk of retroweaving, etc. In JBossWS, I suggest we simply ignore these portablity issues until we want to go prod in Branch_4_0 with the new implementation, at which time jdk5 might be required by Branch_4_0 as well - who knows. Classes that live in org.jboss.ws and org.jboss.test.ws may use jdk5 features View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875944#3875944 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875944 |
From: <tho...@jb...> - 2005-04-29 15:38:01
|
Hi JBossWS, Alex, I have isolated all test failures that are related to marshalling/unmarshalling of complex types. All of these issues have been linked to http://jira.jboss.com/jira/browse/JBXB-15 Anil, there is an issue where the generated schema for array types is invalid. Please have a look at http://jira.jboss.com/jira/browse/JBWS-193 which is a dependency on Alex?s critical work. Generally, there should be a separation of concerns in tools. Currently Java2Schema is mixed up with Java2WSDL. There should be a separate package for java <-> schema with dedicated test cases, etc. Java <-> WSDL is quite different, especially because we will have to support two distinct WSDL versions. Jason, could you please review the validity of the JBXB-15 dependency tests. This is quite important, because Alex will have a critical dependency on these tests. Cheers View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875941#3875941 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875941 |
From: sven.schulz <nu...@jb...> - 2005-04-29 15:37:42
|
Hi, currently I try to use Oracle ADF Faces within JBoss Portal. However there is an issue with JBossRenderRequest not implementing HttpServletRequest (see Stack Trace below). I wonder if it is possible to implement HttpServletRequest in RenderRequestImpl. From a naive point of view it should be possible since an instance of HttpServletRequest is passed into the constructor. But I am not enough in JBoss Portal internals to decide if there are any show stoppers. If anybody with insight thinks it's possible I would try to and submit a patch. Regards, Sven java.lang.ClassCastException: org.jboss.portlet.JBossRenderRequest at oracle.adfinternal.view.faces.ui.ServletRenderingContext.(ServletRenderingContext.java:121) at oracle.adfinternal.view.faces.uinode.FacesRenderingContext.(FacesRenderingContext.java:120) at oracle.adfinternal.view.faces.uinode.FacesRenderingContext.createRenderingContext(FacesRenderingContext.java:97) at oracle.adfinternal.view.faces.renderkit.UIXRenderKit.createResponseWriter(UIXRenderKit.java:278) at javax.faces.webapp.UIComponentTag.setupResponseWriter(UIComponentTag.java:653) at javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:254) at org.apache.myfaces.taglib.core.ViewTag.doStartTag(ViewTag.java:90) at org.apache.jsp.jsp.explorer_jspx._jspx_meth_f_view_0(explorer_jspx.java:92) at org.apache.jsp.jsp.explorer_jspx._jspService(explorer_jspx.java:70) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.portal.portlet.impl.PortletRequestDispatcherImpl.execute(PortletRequestDispatcherImpl.java:71) 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.portal.server.servlet.CommandFilter.doFilter(CommandFilter.java:54) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510) at org.jboss.portal.portlet.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:111) at org.apache.myfaces.context.portlet.PortletExternalContextImpl.dispatch(PortletExternalContextImpl.java:169) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:242) at oracle.adfinternal.view.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:146) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300) at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:292) at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:349) at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:258) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:154) at javax.portlet.GenericPortlet.render(GenericPortlet.java:394) at org.jboss.portal.portlet.invocation.DispatcherInterceptor.invokeRequest(DispatcherInterceptor.java:143) at org.jboss.portal.portlet.invocation.DispatcherInterceptor.invoke(DispatcherInterceptor.java:171) at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213) at org.jboss.portal.portlet.invocation.PreferencesInterceptor.invoke(PreferencesInterceptor.java:93) at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213) at org.jboss.portal.server.invocation.component.ContextDispatcherInterceptor$InvokeNextCommand.execute(ContextDispatcherInterceptor.java:94) 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.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:49) at javax.servlet.http.HttpServlet.service(HttpServlet.java:697) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:552) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510) at org.jboss.portal.server.invocation.component.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:58) at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213) at org.jboss.portal.core.invocation.AccessControlInterceptor.invoke(AccessControlInterceptor.java:125) at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213) at org.jboss.portal.server.invocation.component.CacheInterceptor.invoke(CacheInterceptor.java:74) at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213) at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:238) at org.jboss.portal.server.Component.invoke(Component.java:173) at org.jboss.portal.server.invocation.portal.MainDispatcherInterceptor.invoke(MainDispatcherInterceptor.java:93) at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213) at org.jboss.portal.core.invocation.ViewInterceptor.invoke(ViewInterceptor.java:114) at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213) at org.jboss.portal.server.invocation.portal.TargetInterceptor.invoke(TargetInterceptor.java:153) at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213) at org.jboss.portal.core.invocation.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:117) at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213) at org.jboss.portal.core.invocation.UserContextInterceptor.invoke(UserContextInterceptor.java:91) at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213) at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:238) at org.jboss.portal.server.PortalServer.invoke(PortalServer.java:195) at org.jboss.portal.server.servlet.AbstractMainServlet.invoke(AbstractMainServlet.java:62) at org.jboss.portal.server.servlet.AbstractMainServlet.doGet(AbstractMainServlet.java:55) at javax.servlet.http.HttpServlet.service(HttpServlet.java:697) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.portal.core.servlet.TransactionFilter$1.run(TransactionFilter.java:78) at org.jboss.portal.common.transaction.Transactions.requiresNew(Transactions.java:75) at org.jboss.portal.core.servlet.TransactionFilter.doFilter(TransactionFilter.java:74) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:150) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:54) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:595) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875940#3875940 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875940 |
From: <tho...@jb...> - 2005-04-29 15:36:32
|
Hi JBossWS, Alex, I have isolated all test failures that are related to marshalling/unmarshalling of complex types. All of these issues have been linked to http://jira.jboss.com/jira/browse/JBXB-15 Anil, there is an issue where the generated schema for array types is invalid. Please have a look at http://jira.jboss.com/jira/browse/JBWS-193 which is a dependency on Alex?s critical work. Generally, there should be a separation of concerns in tools. Currently Java2Schema is mixed up with Java2WSDL. There should be a separate package for java <-> schema with dedicated test cases, etc. Java <-> WSDL is quite different, especially because we will have to support two distinct WSDL versions. Jason, could you please review the validity of the JBXB-15 dependency tests. This is quite important, because Alex will have a critical dependency on these tests. Cheers View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875939#3875939 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875939 |
From: <ad...@jb...> - 2005-04-29 14:17:56
|
Ok, the ANY/use case xml would be "a nice to have" to for the GenericBeanFactory. Bill is already using it to deploy advice factories via the MC. I'll get on with checking/fixing/completing your tests/assertions. P.S. You didn't answer my question, do you want bug reports here or in JIRA? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875924#3875924 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875924 |
From: <ad...@jb...> - 2005-04-29 14:04:39
|
My question was why does it return null rather than throwing an exception? I know the reason is the namespace is missing/mismatched, but a user won't :-) JBossXB has a better chance at giving a reasonable error message than anything I could do: | Unmarshaller unmarshaller = UnmarshallerFactory.newInstance().newUnmarshaller(); | KernelDeployment deployment = (KernelDeployment) unmarshaller.unmarshal(url.toString(), schemaBinding); | if (deployment == null) | throw new DeploymentException("Unable to parse " + url + " it is not well formed."); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875923#3875923 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875923 |
From: <ale...@jb...> - 2005-04-29 12:41:03
|
That's because of this change | <?xml version="1.0" encoding="UTF-8"?> | -<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | +<deployment> | + <!--xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="urn:jboss:xml-deployer xml-deployer_1_0.xsd" | - xmlns="urn:jboss:xml-deployer"> | + xmlns="urn:jboss:xml-deployer"--> | <bean name="SimpleBean1" | class="org.jboss.test.xml.pojoserver.SimpleBeanImpl"> | <property name="aList"> Now the qualified name of the deployment element is QName("deployment"), not QName("urn:jboss:xml-deployer", "deployment") which is used in the schema binding. So, it is just not recognized. BTW, currently, in the XSD all attributes belong to the default/empty namespace, not the urn:jboss:xml-deployer. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875904#3875904 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875904 |