September 2008 - jboss-dev-forums

[Design of JBoss Portal] - Re: Portal 2.7 with Postgres

by dloebbe

Hi all, am I the only one with this problem or is this the wrong forum? Thanks, Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176708#4176708 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176708

17 years, 6 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: Using customized RMI socket factory with JBOSSSerializat

by yaishb

"clebert.suconic(a)jboss.com" wrote : I'm sorry I didn't realize this post before... | | This would require some debugging.... Maybe a testcase to reproduce this problem. | | | With the information you sent, I have no idea what's happening. Ok, here it comes... I've extended the Socket class: | public class JBOSSSocket extends Socket | { | /* The InputStream used by the socket. */ | private InputStream in = null; | | /* The OutputStream used by the socket */ | private OutputStream out = null; | | public JBOSSSocket( String host, int port ) throws UnknownHostException, IOException | { | super( host, port ); | } | | public JBOSSSocket() | { | super(); | } | | /* | * Returns a stream of type XorInputStream. | */ | public synchronized InputStream getInputStream() throws IOException | { | if( in == null ) | { | in = new JBossObjectInputStream( super.getInputStream() ); | } | return in; | } | | /* | *Returns a stream of type XorOutputStream. | */ | public synchronized OutputStream getOutputStream() throws IOException | { | if( out == null ) | { | out = new JBossObjectOutputStream( super.getOutputStream() ); | } | return out; | } | | } | I've extended the ServerSocket class: | public class JBOSSServerSocket extends ServerSocket | { | /* | * Constructor for class XorServerSocket. | */ | public JBOSSServerSocket( int port ) throws IOException | { | super( port ); | | } | | /* | * Creates a socket of type XorSocket and then calls | * implAccept to wait for a client connection. | */ | public Socket accept() throws IOException | { | Socket s = new JBOSSSocket(); | implAccept( s ); | return s; | } | | } | | Then, I've extended RMIServerSocketFactory: | | public class JBOSSServerSocketFactory implements RMIServerSocketFactory | { | | @Override | public ServerSocket createServerSocket( int port ) throws IOException | { | // TODO Auto-generated method stub | return new JBOSSServerSocket( port ); | } | | } | | Then, I've extended RMIClientSocketFactory: | | public class JBOSSClientSocketFactory implements RMIClientSocketFactory, Serializable | { | | public JBOSSClientSocketFactory() | { | super(); | } | /** | * | */ | private static final long serialVersionUID = 1L; | | @Override | public Socket createSocket( String host, int port ) throws IOException | { | return new JBOSSSocket( host, port ); | } | | } | | In the server side application, instaed of using: | | Remote stub = UnicastRemoteObject.exportObject( this, 0 ); | Naming.rebind( name, stub ); | | I changhed to | | Remote stub = UnicastRemoteObject.exportObject( this, 0, new JBOSSClientSocketFactory(), new JBOSSServerSocketFactory() ); | | Naming.rebind( name, stub ); | | After all that, I started the server side application and the client side application. As I mentioned before, when the client side application is booting, it performs 2000 calls of Naming.lookup() with the url of the server application. After few calles an exception raised: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:597) at sun.rmi.transport.DGCClient$EndpointEntry.(DGCClient.java:231) at sun.rmi.transport.DGCClient$EndpointEntry.lookup(DGCClient.java:202) at sun.rmi.transport.DGCClient.registerRefs(DGCClient.java:120) at sun.rmi.transport.ConnectionInputStream.registerRefs(ConnectionInputStream.java:80) at sun.rmi.transport.StreamRemoteCall.releaseInputStream(StreamRemoteCall.java:138) at sun.rmi.transport.StreamRemoteCall.done(StreamRemoteCall.java:292) at sun.rmi.server.UnicastRef.done(UnicastRef.java:431) at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source) at java.rmi.Naming.lookup(Naming.java:84) at com.commons.pattern.barakota.HashRAMRMIClient.lookup(HashRAMRMIClient.java:483) at com.commons.pattern.css.rmi.RMICSSClient.initializeDelegatesPool(RMICSSClient.java:70) at com.commons.pattern.css.CSSPeer.init(CSSPeer.java:35) at com.commons.pattern.barakota.HashRAMRMIClient.(HashRAMRMIClient.java:36) at com.storing.context.StoringContext$HashRAMBooter.run(StoringContext.java:908) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) If running both application without the customized RMI socket factory, everything working without any problems. Can you please assist with debugging this behaviour? Thanks, Barak. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176686#4176686 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176686

17 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Major refactoring of the jbpm3 core test suite

by tom.baeyens＠jboss.com

deleting deployed definitions and checking if no records are left seems more error prone to me then just deleting all records in the db. but what you suggest works and that is the most important part. it's your call. i don't think the same solution will hold in jbpm 4 as i'm not sure that we'll have the same behaviour for deletion of process definitions. i think it might be wise to have two separate methods: deleteAllExecutions and deleteProcessDefinition. Then deleteProcessDefinition could throw an exception if process executions are still around. but that decision is for later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176685#4176685 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176685

17 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - JNDI Bindings

by ALRubinger

I'd like to nail down JNDI Bindings at the EJB level, interface level, etc for GA. We'd discussed this previously in http://www.jboss.com/index.html?module=bb&op=viewtopic&t=139843 S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176636#4176636 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176636

17 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Major refactoring of the jbpm3 core test suite

by kukeltje

I made some tests for some more complex jBPM usage and had to adapt them to what Thomas did (great job). Just deleting each generated processDefinition seems to delete all related processInstances, logs etc... so it was as simple as putting a try/finally around my test and indeed keeping track of what processDefinitions I deployed. If we adapt all tests to deploy via a deployProcessDefinitions method of the AbstractDBTestCase, it can keep track of all of them and automatically undeploy/delete at teardown. That would get rid of all try/catches again. The only thing is that the System.exit stops the tests, but Eclipse thinks JUnit is still running... Initially (when I updated from SVN, I was confused.... The FIXME can have a little more explanation, but now I know this, it does not realy bother me View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176635#4176635 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176635

17 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Removing SFSB in HttpSessionListener

by bstansberry＠jboss.com

I decided to skip doing the aforementioned matrix of what's rational and not rational. The behavior an end user would want depends on what they do in their listener. So, I've focused on creating an API for a pluggable policy where users can provide an implementation that tells the clustered session manager exactly what notifications to emit. Class name of the policy impl to use would be specified in jboss-web.xml. For now we'd ship two standard impls, one of which provides the existing behavior, one of which suppresses HttpSessionListener and HttpSessionAttributeListener notifications when a session is expired due to undeploy. To have a look at what I've done, see https://svn.jboss.org/repos/jbossas/branches/Branch_4_2/tomcat/src/main/o... and the other classes in the same package. Basically, when an event occurs, before invoking on listeners we ask the policy if invoking on them is allowed for the given event. We pass as params an enum describing the type of event, a data object describing the calling node's relationship to the session (e.g. is it active on this node, or are we just providing backup) and a boolean indicating whether the event is due to locally originated activity (as opposed to activity originating on another node.) Note the class javadoc for ClusteredSessionNotificationPolicy where I emphasize that the container is not necessarily capable of supporting all the invocations that the policy might allow. This is critical as it allows me to provide today a policy API where users can state what they allow, without having at the same time to provide support for notifications not mandated by the servlet spec. For example, we currently don't issue HttpSessionListener.sessionCreated() notifications when a session is created on another node. As more non- spec-mandated notifications are supported, existing policy impls can appropriately allow/disallow the new notifications. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176619#4176619 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176619

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: PackageInformation retrieved from wrong jar

by alesj

"scott.stark(a)jboss.org" wrote : So your going to change getPackageInformation() to take a class rather than a package name? | No, he added new method which takes classname and package name. For back compatibility this method calls previous method, only to be overridden in VFSClassLoaderPolicy. There, instead of using package as path, we use class path. - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloadi... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176611#4176611 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176611

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: PackageInformation retrieved from wrong jar

by scott.stark＠jboss.org

So your going to change getPackageInformation() to take a class rather than a package name? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176609#4176609 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176609

17 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Merging Branch_Stable and Branch_CP as a single branch...

by clebert.suconic＠jboss.com

Looking at the diffs from both branches, they basically differ on the documentation, few config changes and the security integration code. As we were talking today, if we separate the necessary integration layer (configs and eventually java classes) we could have a single branch for both JBoss5 and JBoss4. The only big difference now is the Executors change done by Howard, but if we choose to keep only one branch maybe that should be okay. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176597#4176597 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176597

17 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Handling soft versus hard pooledInvoker exceptions in JR

by bstansberry＠jboss.com

There's a code freeze in effect for trunk; please wait on that. Dimitris will send out a notice on jboss-development(a)lists.jboss.org when lifted (probably 24 to 48 hours). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176585#4176585 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176585

17 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 2008