August 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Remoting, Unified Invokers] - Re: Encryption in Remoting

by mazz＠jboss.com

What's the use-case? Do you just want encryption without the need for certificates? If so, Remoting has this capability now - you can use SSL transports (https, sslsocket) and configure it so you don't need certs on either end (i.e. just use SSL for encryption without authentication). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965317#3965317 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965317

19 years, 7 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Encryption in Remoting

by clebert.suconic＠jboss.com

If you can't find a parameter to flush data without close the stream... What about to use a fake output stream to change the behavior on .close operations: It's kind of a hack... but if there isn't another option. import java.io.IOException; | import java.io.*; | | public class FlushOnCloseOutputStream extends OutputStream | { | OutputStream delegate; | | public void close() throws IOException { | delegate.flush(); // here | } | | public boolean equals(Object arg0) { | return delegate.equals(arg0); | } | | public void flush() throws IOException { | delegate.flush(); | } | | public int hashCode() { | return delegate.hashCode(); | } | | public void write(byte[] b, int off, int len) throws IOException { | delegate.write(b, off, len); | } | | public void write(byte[] b) throws IOException { | delegate.write(b); | } | | public void write(int b) throws IOException { | delegate.write(b); | } | | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965315#3965315 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965315

19 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Bean instantiate order with contextual injection

by alesj

"adrian(a)jboss.org" wrote : | What you have done is added a reference to the class in the SuppliesMetaData | which once the bean gets uninstalled will cause a memory leak. | | UninstalledBeanMetaData (waiting to get reinstalled) -> | SuppliesMetaData -> Class -> ClassLoader (that is supposed to be | garbage collected). Ok, this is then the same as If I would set a value (the demaning class) in the AbstractDependencyMD? So class should only be set in the 'placeholder' DependencyItem? No memory leak problem there? As for MDV[]Node.describeVisit() - it should not add any class refs to MetaData then? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965314#3965314 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965314

19 years, 7 months

1
0
0 / 0

[Design of JBoss IIOP on JBoss] - IIOP CSIv2 Kerberos authentication

by kc7bfi

I was wondering if it was possible to use CVIv2 to authenticate a CORBA client using Kerberos authentication? I know it works with JacORB (I wrote the interceptors) but does it work with JBoss's interceptors? The code looks like it just supports username/password, is that correct? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965310#3965310 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965310

19 years, 7 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Encryption in Remoting

by anil.saldhana＠jboss.com

That is the problem with CipherOutputStream. Unless you close(), data is not flushed across due to buffers waiting for data to be filled. Maybe we should revisit encryption in remoting like the way Scott implemented earlier - a CipherSocket based on Password based encryption. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965308#3965308 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965308

19 years, 7 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Encryption in Remoting

by clebert.suconic＠jboss.com

I just think you shouldn't be calling .close in your streamings at all: Can't you just do: public void write(Object dataObject, OutputStream output) throws IOException | { | if(cipher == null) | throw new IllegalStateException("Cipher is null for algo="+ this.cipherAlgorithm); | output.flush(); | | CipherOutputStream cos = new CipherOutputStream(output, cipher); | | SerializationManager sm = SerializationStreamFactory.getManagerInstance(getSerializationType() | ); | ObjectOutputStream oos = sm.createOutput(cos); | | if(wrappedMarshaller != null) | { | wrappedMarshaller.write(dataObject, oos); | } | else | { | super.write(dataObject, oos); | } | oos.flush(); | // cos.close(); pp remove this and let GC take care of these instances | // oos.close(); //There is a need to close cos | } | Take a look on the other marshallers... they always keep the streaming opened and only use flush(); View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965297#3965297 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965297

19 years, 7 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Encryption in Remoting

by anil.saldhana＠jboss.com

If I remove the explicit cos.close() So I now get: | 2006-08-15 10:27:25,619 ERROR [org.jboss.remoting.transport.socket.ServerThread] failed to process invocation. | java.net.SocketException: Socket closed | at java.net.SocketOutputStream.socketWrite(Unknown Source) | at java.net.SocketOutputStream.write(Unknown Source) | at java.io.BufferedOutputStream.flushBuffer(Unknown Source) | at java.io.BufferedOutputStream.flush(Unknown Source) | at java.io.DataOutputStream.flush(Unknown Source) | at org.jboss.serial.io.JBossObjectOutputStream.flush(JBossObjectOutputStream.java:248) | at org.jboss.serial.io.JBossObjectOutputStream.close(JBossObjectOutputStream.java:261) | at javax.crypto.CipherOutputStream.close(DashoA12275) | at java.io.FilterOutputStream.close(Unknown Source) | at org.jboss.serial.io.JBossObjectOutputStream.close(JBossObjectOutputStream.java:263) | at org.jboss.remoting.marshal.encryption.EncryptingMarshaller.write(EncryptingMarshaller.java:127) | at org.jboss.remoting.transport.socket.ServerThread.versionedWrite(ServerThread.java:484) | at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:463) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965295#3965295 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965295

19 years, 7 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Encryption in Remoting

by anil.saldhana＠jboss.com

Related to http://jira.jboss.com/jira/browse/JBREM-419 I plug in a CipherOutputStream to the JBossObjectOutputStream. The issue with COS is that it needs an explicit close() to flush all the data across. But this causes a socket write error as shown: | [SocketServerInvokerThread-127.0.0.1-0] ERROR org.jboss.remoting.transport.socket.ServerThread - failed to process invocation. | java.net.SocketException: Software caused connection abort: socket write error | at java.net.SocketOutputStream.socketWrite0(Native Method) | at java.net.SocketOutputStream.socketWrite(Unknown Source) | at java.net.SocketOutputStream.write(Unknown Source) | at java.io.BufferedOutputStream.flushBuffer(Unknown Source) | at java.io.BufferedOutputStream.flush(Unknown Source) | at java.io.DataOutputStream.flush(Unknown Source) | at org.jboss.serial.io.JBossObjectOutputStream.flush(JBossObjectOutputStream.java:248) | at javax.crypto.CipherOutputStream.flush(DashoA12275) | at java.io.DataOutputStream.flush(Unknown Source) | at org.jboss.serial.io.JBossObjectOutputStream.flush(JBossObjectOutputStream.java:248) | at org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager.sendObject(JBossSerializationManager.java:95) | at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:84) | at org.jboss.remoting.marshal.encryption.EncryptingMarshaller.write(EncryptingMarshaller.java:123) | at org.jboss.remoting.transport.socket.ServerThread.versionedWrite(ServerThread.java:484) | at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:463) | Clebert mentioned that there may be an issue with JBossOOS close with the following: | public void close() throws IOException { | flush(); | dataOutput.close(); | dataOutput.close(); | } | A copy/paste error. * I do not know yet whether the socket write error is something related to JBossOOS close or the other side closed the socket. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965291#3965291 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965291

19 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - 2.4 Docs updated

by roy.russo＠jboss.com

The 2.4 reference guide has been updated online: http://docs.jboss.com/jbportal/v2.4/reference-guide/en/html/ Examples of consuming wsrp portlets from bea has been added to the wsrp chapter. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965290#3965290 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965290

19 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: CMS portlet extension

by creative77

I believe I did post this originally to the user forum. How it got here I'm not sure but, I am glad someone responded. I did figure out that it did need to be injected. My main grief was that yes, there is an example and information on injecting services. However, there was no reference information for CMS services. This thread was the first I have seen of a CMS service example or reference. This has been a problem for me in my analysis of JBoss portal for a replacement to our company EIP. I just don't see enough support information to figure out the details to make some of the features work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965275#3965275 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965275

19 years, 7 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 August 2006