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

[Design of POJO Server] - Re: Aspectized JACC deployment layer

by wmprice

Was there a dev call? Was this open to anyone? Is this something you guys schedule on a regular basis? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978227#3978227 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978227

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: To merge or not to merge?

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : But I think we are talking about different things, at least from | my understanding of your original post. | | There is a need to merge/hide/override at runtime and this | depends upon the type of metadata (it also includes having the | ability to query where the data came from). | Argreed, but runtime usage vs asking where runtime T.x actually came from seem like two different uses of the composite metadata for the type T. One way to get the runtime view would be to collapse the levels into an instance T. Another would be a T facade over delegating accessors/iterators that do the right thing for each property x of T. "adrian(a)jboss.org" wrote : | The full normalized view should be maintained elsewhere. | I'm not following what you mean by normalized view? "adrian(a)jboss.org" wrote : | When I talk about merging I'm talking about giving the runtime view, | e.g. getting all the resource-refs for a bean (from all levels). | Yes, that is what I would consider as merging as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978226#3978226 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978226

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Aspectized JACC deployment layer

by scott.stark＠jboss.org

And relating this to our call this morning, each component deployer that utilizes jacc can create the kernel bean metadata for the policy configuration instances, and tie that into the kernel bean metadata for the policy configuration container object. Each container would have to declare a dependency on the policy configuration container object. When the kernel bean deployer instantiates the policy configuration container, all deployers will have associated their policy configuration object dependencies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978224#3978224 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978224

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: DTD and schema bindings

by alex.loubyansky＠jboss.com

Not at the moment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978203#3978203 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978203

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: DTD and schema bindings

by adrian＠jboss.org

Ok, is there a way for me to do unmarshal(uri, resolver); and have it spot the dtd and use the correct schema binding? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978199#3978199 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978199

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Summary of approach to HA/Failover

by bstansberry＠jboss.com

I don't think the DistributedReplicantManager code is a very good fit for what you're describing. The DRM is really based on this kind of data structure: Outer Map -- Key = ejb1 -- Value = Inner Map -------------- Key = node1 identifier -------------- Value = replicant (RMI stub, InvokerLocator, your struct etc.) -------------- Key = node2 identifier -------------- Value = replicant for targetting node2 -- Key = ejb2 -- Value = Inner Map Code that "writes" to the DRM (e.g. an EJB deployment process) doesn't care about order; it just publishes a replicant for ejb1. Code that "reads" the DRM usually wants a List of the replicants associated with ejb1. But DRM provides this by iterating through the Inner Map and ordering the responses based on the current JGroups view. Thus the ordering is fixed. Messaging needs: Map -- Key = node1 -- Value = List ----------- element = struct for node3 ----------- element = struct for node4 Here the code that writes has already prepared a properly ordered list based on a pluggable policy. The code that "reads" the DRM needs to get that same list. Trying to change DRM to make a generic class that can handle both use cases is probably more effort than just creating something new. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978194#3978194 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978194

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Aspectized JACC deployment layer

by scott.stark＠jboss.org

We have to be able to build up dependencies across deployers. If the metadata for the mbean/pojo security layer cannot be done this way, then you need a security metadata deployer that runs after deployment type deployers to merge the security metadata to build the proper instances. The naturual place for this is every container needs a dependency on a SecurityDomain object to gain access to the authentication/authorization interfaces. We need to talk through how this can happen such that the jacc policy configuration object lifecycles tie into the top level deployment starting. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978185#3978185 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978185

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Update on metadata progress

by bdecoste

Well, if I can help let me know. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978181#3978181 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978181

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Update on metadata progress

by bill.burke＠jboss.com

anonymous wrote : | Bill, back in Westford we talked about migrating or supporting the old metadata model. I'm just starting new some tasks - do we still want to do that? | Looks like Adrian is doing the work Bill. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978179#3978179 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978179

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: DTD and schema bindings

by alex.loubyansky＠jboss.com

RAR parsing is based purely on ObjectModelFactory API. There is no parsing of DTD nor XSD. The XML is validated by the SAX parser. The only parsing of DTD is used in the DTD-based marshaller. I used Wutka's DTD parser for that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978178#3978178 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978178

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