September 2006 - jboss-dev-forums

[Design of POJO Server] - Re: AbstractJarHandler.isFile/isDirectory and isArchive

by scott.stark＠jboss.org

isArchive uses: - JARStructure, + expects jars to be directories (isDirectory == true). + expects directories that are not also archives (unpacked jars) to have a META-INF to be recognized. - WebInfLibFilter, + accepts isArchive == true as a lib jar + file.isDirectory() == true && JarUtils.isArchive(file.getName()) as a lib jar. These are too lax and violate the servlet spec as only .jar archives are to be accepted to strictly conform to the spec (JBAS-2538). - AbstractDeploymentContext, + A non-archive, non-directory root is defaulted to the metadata location if one has not been set. other isDirectory uses: - WARStructure, + expects jars to be directories (isDirectory == true) and further filers on .war or WEB-INF existence. The general features we need are: - does a file have children - does a file have an input stream, and what is its encoding Marking a file as a directory via isDirectory could achieve the first. I would like to drop the isArchive attribute and add a contentType instead. A null contentType implies there is no meaningful input stream and one would expect null or an error if it was requested. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971454#3971454 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971454

19 years, 6 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Help, can not send email to hotmail.com?

by wrwttkl22

I install a JBossMailServer1.0M4 by default.(see http://wiki.jboss.org/wiki/Wiki.jsp?page=HowToInstallJBossMailServer1.0M4) Certainly, I set a DNS for sending Email out. When I send emails from test@localhost to wrwttkl22(a)163.com, wrwttkl22(a)sohu.com or wrwttkl22(a)126.com, I can receive all with them. But I send an email from test@localhost to wrwttkl22(a)hotmail.com , I can not receive the email with wrwttkl22(a)hotmail.com. why? hlep! thank you! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971449#3971449 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971449

19 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Registry Design

by kurt.stam＠jboss.com

Thanks Anil, I'm going down that road. For now I'm making SOAP calls to trace down the calls. When I deploy juddi to tomcat this works great, however when the juddi.war is deployed to jboss-4.0.4GA most calls result in a stack trace: 21:14:33,000 INFO [STDOUT] 2006-09-13 21:14:33,000 [http-0.0.0.0-8080-2] INFO org.apache.juddi.util.jdbc.ConnectionManager - Using JNDI to aquire a JDBC DataSource with name: java:comp/env/jdbc/juddiDB 21:14:33,359 INFO [STDOUT] 2006-09-13 21:14:33,359 [http-0.0.0.0-8080-2] ERROR org.apache.juddi.registry.AbstractService - NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. at org.apache.xerces.dom.AttrNSImpl.setName(Unknown Source) at org.apache.xerces.dom.AttrNSImpl.(Unknown Source) at org.apache.xerces.dom.CoreDocumentImpl.createAttributeNS(Unknown Source) at org.apache.xerces.dom.ElementImpl.setAttributeNS(Unknown Source) at org.jboss.ws.soap.SOAPElementImpl.setAttributeNS(SOAPElementImpl.java:616) at org.jboss.util.xml.DOMUtils.copyAttributes(DOMUtils.java:315) at org.jboss.ws.soap.SOAPFactoryImpl.createElement(SOAPFactoryImpl.java:81) at org.jboss.ws.soap.SOAPBodyImpl.addDocument(SOAPBodyImpl.java:82) at org.apache.juddi.registry.AbstractService.doPost(AbstractService.java:192) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) I'm trying to figure out what's going on here. I'd like to have this working before creating the local call mechnism, also because it may come in handy to make soap calls from some client tool. I think we want to insert data using a client tool. More people seem to report this issue, using xalan and xerces. Maybe it's a conflict with the libs in java5. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971445#3971445 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971445

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: state transfer failure handling

by manik.surtani＠jboss.com

"bstansberry(a)jboss.com" wrote : That behavior of allowing persistent to proceed after a failure with transient goes back a long way. Why is this though? I can see how this can be useful in some cases, but in others (e.g., if passivation is in use) it's usefulness may be limited. First impressions and all so far, but I'd lean towards an atomic approach here. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971440#3971440 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971440

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Runtime changes of cache config elements

by scott.stark＠jboss.org

The api is associated with the profile service and is rooted at the org.jboss.deployers.spi.management.ManagementView. There is simple org.jboss.deployers.spi.management.ManagedObject representation of a bean's management interface. How the ManagedObject is obtained for a component is a function of the deployer associated with the component. So far we have not gotten to how the deployers extract the ManagedObject from a deployment metadata. We'll have to define annotations and schemas for this. Adrian did create a org.jboss.mx.mxbean.MXBean prototype that illustrates some concepts of the jdk6 MXBean: http://download.java.net/jdk6/docs/api/javax/management/MXBean.html http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89432 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971435#3971435 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971435

19 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Have remoting support a non invocation based model

by scott.stark＠jboss.org

At some level we should align with the java.util.concurrent.Executor/ExecutorService/Future/CompletionService/ as a simple api for asynchronous invocations. This still applies to the invocation based model. I view what Tim is asking for as more of an expansion of the transport channel abstraction spi that essentially allows for more interception of raw transport packets. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971428#3971428 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971428

19 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Extracting load balancing classes from AS cluster module

by scott.stark＠jboss.org

1) We have to drop the old interceptor/invocation if we are going to be able to unify and resuse aspects. 2-4) LoadBalancePolicy should ideally just have an abstraction of the invocation payload and metadata as that is all that it would use rather than a dependency on the org.jboss.aop.joinpoint.Invocation. I thought we were breaking out the metadata from the Invocation, but its still there. Still, I would just have chooseTarget(FamilyClusterInfo, Map) and if a policy needs the Invocation it can be added by interceptor. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971423#3971423 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971423

19 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Moving core o.j.invocation classes to common

by scott.stark＠jboss.org

These classes really intersect with the aop classes, and we have to get to a reusable interceptor model based on the aop stuff to allow for aspects to be resued. Aop has duplicate MarshalledValue* style classes as well. A split of the aop as needed into something in the aop-mc-int project of the microcontainer: https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971418#3971418 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971418

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: state transfer failure handling

by bstansberry＠jboss.com

FYI, please note that the "current" above means the current HEAD code, which works somewhat differently from the currently released code (1.4.0.SP1). In 1.4.0.SP1: If the state provider has a failure marshalling transient, associated or persistent state, it returns null for the entire state transfer. The recipient interprets the null as a failure. On the recipient side, if there is a problem integrating the transient state, associated state is *not* integrated. Don't remember why I did it that way; probably because associated is useless without the transient state. However, if there's a problem integrating either transient or associated state, integration of persistent state is still allowed to proceed. That behavior of allowing persistent to proceed after a failure with transient goes back a long way. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971375#3971375 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971375

19 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Have remoting support a non invocation based model

by tom.elrod＠jboss.com

Below is list of possibly scenarios for making remote calls through remoting. Legend: thread blocks = --| thread returns = --> 1. synchronous call caller thread -- remoting client --| -- NETWORK -- pooled processing thread -- handler Calling thread goes through remoting client call stack till makes network call and blocks for response. The pooled processing thread will call on the handler, get the response from the handler and write it back to the network where will be picked up by the blocking caller thread. 2. asynchronous call - client side caller thread --> remoting client (worker thread) --| -- NETWORK -- pooled processing thread -- handler Calling thread makes invocation request and returns before making network invocation. Remoting client pooled thread takes invocation and makes call over the network. From here is same as case 1, but response is just thrown away. 3. asynchronous call - server side caller thread -- remoting client --| -- NETWORK -- pooled processing thread --> pooled async processing thread -- handler Calling thread goes through remoting client call stack till makes network call and blocks for response. The pooled processing thread will hand off invocation to a pooled async processing thread and will return (thus unblocking the calling thread on the client). The pooled async processing thread will call on handler, get response, and throw it away. 4. non-blocking asynchronous call caller thread -- remoting client --> -- NETWORK -- pooled processing thread -- handler Calling thread goes through remoting client call stack till makes network call where will only write to network, but not wait (block) for server response (see http://jira.jboss.com/jira/browse/JBREM-548). The pooled processing thread will call on the handler, get the response from the handler and write it back to the network. Not sure yet what will have to be done for this implementation as don't know if will be a problem with pooled processing thread sending data back to network with no one on the other side. Note: in the above scenarios, there is actually an accept thread on server that gets socket from server socket and passes onto a pooled processing thread and goes back to listening for next socket request. Have removed it from thread stack diagram to make easier to read. 1 - 3 are already available within remoting today. 4 is scheduled to be implemented. For 2 - 4, only getting request to server is covered. Getting response back to client will require callbacks. Also important to remember that remoting has one API that all the transport implementations support. In order to change that API for new desired behavior, all the transports must be able to support it (how it supports it is an implementation detail). As for sending raw data, this is possible to do on the client side by using the Client.RAW property in the invocation metadata map (which will send only the raw payload object and not wrap in InvocationRequest object). However, this will only be honored by the remoting http server (CoyoteInvoker). The other remoting servers (i.e. socket server invoker), will throw an exception when it does not get payload of type InvocationRequest. I can change the code for the other server invokers to behave like the CoyoteInvoker so can accept raw payload objects. The only issue with this is then loose all the extra remoting info stored within the remoting InvocationRequest (such as client sessiond id and subsystem). So this means that won't be able to a) have multiple handlers registered with connector as no way to determine which subsytem to route call to and b) be able to determine which client made call within handler based on InvocationRequest passed. Would also need to make sure don't use the Client.RAW when using addCallbackListener() method or will loose client session id and no way to setup callbacks on server side. When using RAW for http, currently work around this by using data from the http header to provide the client session id and subsystem. The same argument goes for server response being of type InvocationResponse, in that it contains extra metadata than can be used on the client side. However, can change the other transports to behave like the http server (in that if the request payload is not of type InvocationRequest, when will not wrap the handler's response object in a InvocationResponse). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971367#3971367 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971367

19 years, 6 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-dev-forums September 2006