September 2006 - jboss-dev-forums

[Design of POJO Server] - Re: VFS issues

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | When I originally prototype the vfs code, I did start out with URI. The problem was that you always had to go to the URL in order to get the io streams, or come up with another URI handler framework. Its a decision we need to make. | But isn't that the whole point. If the URI really is a URL then the handler extends AbstractURLHandler and gets (or it can reimplement it). | public InputStream openStream() throws IOException | { | checkClosed(); | return url.openStream(); | } | But if it is not really URL based then the handler has to provide its own implementation. i.e. a mapping to the real resource it is trying to represent with the more logical URI. The real issue is whether you also need to write a URLStreamHandler besides the virtual file stuff. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970399#3970399 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970399

19 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: jboss.xml dtd with jboss service element?

by kapilanand

Well annotations can define the meta data ok, but i dont intend to use them for deployment related details. Deployment descriptor is the right place for it. For example I used jboss.xml for the local-jndi-name only and used annotations for Management interface, Local interface and declaring the class as service, but this hard-codes the servicename. I was trying to figure out a way to override the service name from jboss.xml, and that's why looking for the DTD. Of course i can replace the annotation values in the source at the time of build , but that requires my code to be checked-out (writable), plus I dont know how the java5 enabled IDE behave on scanning the variable names instead of the valid values. So even a hard coded deployment descriptor is of same category. If xdoclet is out of picture, i would prefer to store templates for deployment-descritors and populate them to generate packages for release. In case you have a better idea, do let me know. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970397#3970397 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970397

19 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS issues

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : The AbstractVirtualFileHandler does have the reference, | it is just via a virtual method: getRootURL(); | | The idea is that we might want to support virtual files | that are not directly URL based, but do provide a unique identifier. | Ok, so I need to write out the rootURL to be able to read it back in. "adrian(a)jboss.org" wrote : | In fact, the api should really be URI based to make this a real possibility. | With only those handlers that are based on a real URL having | a URI that can be used to recreate the URL. | | In anycase, don't you have a problem that each deserialized | virtual file handler will end up in its own copy of the context? | That is unless the locator holds some kind of a map of rootURL -> context. | When I originally prototype the vfs code, I did start out with URI. The problem was that you always had to go to the URL in order to get the io streams, or come up with another URI handler framework. Its a decision we need to make. Yes, we would need a mapping in context factory to avoid explosion of vfs contexts on deserialization. "adrian(a)jboss.org" wrote : | Also, I think you should make VirtualFileHandler implement Serializable | as a part of the intended contract rather doing it on each implementation. | No problem with that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970393#3970393 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970393

19 years, 7 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Choosing the running node for HASingletons

by bstansberry＠jboss.com

Alex can do it; JIRA is http://jira.jboss.com/jira/browse/JBAS-3636 . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970388#3970388 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970388

19 years, 7 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: StdServerSession/StdServerSessionPool -- JmsServerSessio

by weston.price＠jboss.com

You just never can let one post go by without saying something can you? No matter how useless or insulting. Don't you have a laptop to buy? :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970386#3970386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970386

19 years, 7 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: StdServerSession/StdServerSessionPool -- JmsServerSessio

by bill.burke＠jboss.com

Well, we'll find out how good it is when EJB3 RC9 goes out! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970381#3970381 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970381

19 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: jboss.xml dtd with jboss service element?

by bill.burke＠jboss.com

you can't be serious, XDoclet? Use annotations man... Asfar as your other question. There should be a jboss_5_0.xsd someplace. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970378#3970378 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970378

19 years, 7 months

1
0
0 / 0

[Design of JBoss Labs] - Re: QA Metrics for JEMS Matrix

by damon.sicore＠jboss.com

Sounds good, but our JBoss Labs build will have the worst statistics ever. ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970374#3970374 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970374

19 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS issues

by adrian＠jboss.org

The AbstractVirtualFileHandler does have the reference, it is just via a virtual method: getRootURL(); The idea is that we might want to support virtual files that are not directly URL based, but do provide a unique identifier. In fact, the api should really be URI based to make this a real possibility. With only those handlers that are based on a real URL having a URI that can be used to recreate the URL. In anycase, don't you have a problem that each deserialized virtual file handler will end up in its own copy of the context? That is unless the locator holds some kind of a map of rootURL -> context. Also, I think you should make VirtualFileHandler implement Serializable as a part of the intended contract rather doing it on each implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970370#3970370 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970370

19 years, 7 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Breaking clustering code out of the AS

by scott.stark＠jboss.org

The "jbossas/projects" namespace is meant for code that can be released independent of jbossas. Its mostly an artifact of wanting to preserve history for projects that historically were in the jbossas cvs repository and are now being broken out. I don't see that ha-client and ha-server projects should be separate svn trees with their own branching structure. Rather I would expect them to share the same release and use a structure like: https://svn.jboss.org/repos/jbossas/projects/cluster/ha/trunk/{client,ser... https://svn.jboss.org/repos/jbossas/projects/cluster/ha/branches/.../{cli... The main issue I see with breaking this out and tieing into remoting is the proxy factory piece. There are multiple interceptor models floating around due to independent evolution of jmx, ejb2, and aop. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970366#3970366 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970366

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 September 2006