September 2006 - jboss-dev-forums

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

by tom.elrod＠jboss.com

So if I understand correctly, the following go into microcontainer: Invocation InvocationContext InvocationKey InvocationType Invoker JBossLazyUnmarshallingException PayloadKey SecurityActions and the following go into common: MarshalledInvocation MarshalledValue MarshalledValueInputStream MarshalledValueOutputStream correct? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971625#3971625 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971625

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Deployers, ContextData and MangedObjects

by scott.stark＠jboss.org

Yes, but these just look like different items in runtime metadata hierarchy. As I see it there is a scope aspect setting up the proper starting point for metadata hierarchy key, and an aspect like enc retrieves the approriate context by looking up this using the key established by the scope aspect. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971623#3971623 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971623

19 years, 6 months

1
0
0 / 0

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

by scott.stark＠jboss.org

2) 9.5 only lists jars as the pattern for input. It does not say to explicitly exlude archives of other names but it showed up in support cases as inconsistent behavior with the base tomcat and other containers when we relaxed it. ? The /WEB-INF/lib/*.jar area for Java ARchive files. These files contain servlets, beans, and other utility classes useful to the Web application. The Web application class loader must be able to load classes from any of these archive files. 3) This should be something we should externalize to control alternate structure related behaviors. 4) It should be an extension of the current JarUtils suffix mapping behavior into a full file type attribute registry. Content type and other attributes like isSar, isLink, etc. could be managed from there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971618#3971618 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971618

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - VFS links

by scott.stark＠jboss.org

I have an initial usecase of links in the vfs working. See the org.jboss.test.virtual.test.TestFileVFS.testWarLink which illustrates creating a virtual war from different VFS paths: + A VFS rooted at the container/src/resources/tests/vfs/links + A VFS link file container/src/resources/tests/vfs/links/war1.vfslink.properties which maps its self to test-link.war with children: + + WEB-INF/classes pointing to container/output/eclipse-classes-tests/ + + WEB-INF/lib pointing to container/src/resources/tests/vfs/sundry/jar >From the VFS root you can find the test-link.war, test-link.war/WEB-INF/{classes,lib} as well as classes and jars in these link directories. There are some TODOs in the code for issues regarding inconsistencies in the VirtualFileHandlers like the URI of the link targets not matching the URI you would build from the VFS path/name components because of the link, and other consistency issues that can arise if you try to walk up and down the parent/child handlers. Another issue is that the links are part of the FileSystemContext and not a general feature of the VFS. To resolve some of the consistency issues this may need to be a first class construct in the base spi. Whether or not a given VFSContext supports links would need to show up there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971609#3971609 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971609

19 years, 6 months

1
0
0 / 0

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

by vblagojevic＠jboss.com

So lets bundle reading/writing transient and associated state as one atomic step since they deal exclusively with in-memory tree and reading/writing persistent state as another atomic step. Lets call them step 1 and step 2. Is the algorithm you have in mind something along the lines of: Reading: obtain lock on transient node at integration point do step 1 if any part of step 1 fails clear transient tree at integration point and clear pojo map release lock on transient node at integration point obtain lock on CacheLoaderManager at node integration point if (step 1 failed and it is a specific case Brian mentioned) or (step 1 success) do step2 if step 2 fails clear cacheloader at node integration point release lock on CacheLoaderManager at node integration point Writing: obtain lock on transient node do step 1 release lock on transient node obtain lock on CacheLoaderManager at node generation point if (step 1 failed and it is a specific case Brian mentioned) or (step 1 success) do step2 release lock on CacheLoaderManager at node generation point Any corrections or suggestions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971597#3971597 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971597

19 years, 6 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - JBCS & ClamAV Antivirus

by sappenin

All, I've written some code that integrates ClamAV with JBCS to provide server-side antivirus protection, and thought I'd share it with the community. I'm putting together a page detailing how to install everything -- I'll post that shortly as well as the code I've written. BACKGROUND There are 3 components to JBCS Antivirus. First is ClamAV, a server-based, opensource antivirus project, which can be downloaded from their site, and will need to be installed. Second and third are 2 JBCS MBeans (and a small tidbit of config XML to integrate this into JBCS). The first is the ClamAV service MBean, which provides functionality that bridges JBCS/Java to the ClamAV daemon (running either locally or on a remote machine). The second MBean is a JBCS Maillistener that can be plugged into any of the JBCS mailListenerChains. Unfortunately, ClamAV is not Java, and it provides only 2 facilities to scan for viruses: 1.) Scan a file; 2.) Scan a binary STREAM over a socket. PRESENT CONSIDERATIONS My implementation uses the latter via a network stream. In my testing I have gotten everything working, although I am forced to scan a whole message at a time. So, for example, if a given message has 3 message bodies, but only one is infected, the code will basically just report back that a virus was found (it doesn't specify in which message body). There is another set of functionality that I have implemented which allows ClamAV to check a single message body at a time, such that in the example above, a message with 3 bodies, and only 1 infected, would report back which MessageBody ids are infected. That way, the ClamAVMailListener code could lose the infected body but retain the UN-infected bodies. Unfortunately (again), in my testing of this, ClamAV does not detect a sample virus in this scenario. I beleive this because ClamAV is designed to be able to scan an entire message, not individual message components. Thus, if a Base64 encoded "attachment" is sent to clamAV without the rest of the contextual information found in a MIME message, ClamAV does not know to "inspect" the Base64 data, and thus a virus signature is not detected. Once JBCS has better MIME message support (Andy alluded to forking the MIME4j code) I should be able to get a MimeBody part, decode the base64 attachment (if it exists), and send that to ClamAV. Thus, in version 2 of this plugin, we should be able to deal with infected message bodies individually. MOVING FORWARD For the moment, I would appreciate some information from the community as to how this should function: 1.) If a message has a single infection, but 1 or more uninfected message bodies, what should happen to the message? 2.) If a message has a single attachment that is infected, what should happen to the message? Should it bounce? Should it be "cleansed" (i.e., reset the subject, remove the infected body, and add a note in the message body saying that it was cleaned), or some other functionality? Thanks! David View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971590#3971590 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971590

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Locking tree before setting initial state

by bstansberry＠jboss.com

After I thought through the algorithm some more, I don't think we need it for the immediate issue. So adding that could be more of a future thing, maybe 3.0 or something. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971588#3971588 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971588

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Locking tree before setting initial state

by bela＠jboss.com

Hmm, not so good because that would mean I have to add another callback blockDone() in the MembershipListener... What do we do about compatibility ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971585#3971585 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971585

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Locking tree before setting initial state

by vblagojevic＠jboss.com

Ok I see. You believe that an event/callback at JChannel level indicating that FLUSH completed is useful. I think soo too. Lets see what Bela says. I understand your algorithm for locking better now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971584#3971584 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971584

19 years, 6 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Deleting Message Bodies

by sappenin

All, When/how do Message bodies get deleted? I don't see a delete Messagebody function in the MailboxService class, nor in the MailBody Manager. Does this happen automagically when the last MessageData to reference a given set of MessageBodies gets deleted? Thanks! David View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971576#3971576 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971576

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