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

[Design the new POJO MicroContainer] - Re: AbstractController add/removeControllerContext

by alesj

"adrian(a)jboss.org" wrote : "alesj" wrote : | | Is this OK? | | Or too ugly hack? | That's the way I told you to do it before. | To do an ugly hack? :-) "adrian(a)jboss.org" wrote : | The whole point of protected and "friend" in c++ is to allow restricted access | to implementation details, but you need to make sure the access makes sense. | | i.e. Is it possible that the implementation will change down the road making these methods unsupportable? If/when the whole scoping impl changes, it will be really easy to strip out the current impl - simply removing the Scoped(Kernel)Controller and re-connect the AbstractKernelController with AbstractController. Since those two classes + PreInstallAction are the only one's who know what the scope is. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4073017#4073017 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4073017

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractController add/removeControllerContext

by adrian＠jboss.org

"alesj" wrote : | Is this OK? | Or too ugly hack? That's the way I told you to do it before. The whole point of protected and "friend" in c++ is to allow restricted access to implementation details, but you need to make sure the access makes sense. i.e. Is it possible that the implementation will change down the road making these methods unsupportable? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4073012#4073012 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4073012

18 years, 8 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS project structure has changed

by maeste

"darran.lofthouse(a)jboss.com" wrote : Where is a good place to put user branches now? Personally I like a single area using my name that I can branch as many projects into as I need while working on issues. I have the same question too. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4073008#4073008 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4073008

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractController add/removeControllerContext

by alesj

+ added missing write locks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072976#4072976 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072976

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractController add/removeControllerContext

by alesj

"alesj" wrote : | e.g. ScopedKernelController extends AbstractKernelController extends ScopedController extends AbstractController | If I do this it works and nothing is public. ScopingKernelController has package protected methods: | void addControllerContext(KernelControllerContext context) | { | super.addControllerContext(context); | } | | void removeControllerContext(KernelControllerContext context) | { | super.removeControllerContext(context); | } | | void release() | { | getParentController().removeController(this); | setUnderlyingController(null); | setParentController(null); | parentKernel = null; | } | since it is only accessed in PreInstallAction, which is in the same package. The only change to AbstractKernelController is that it extends ScopedController instead of AbstractController. This is how ScopedController looks like: | /** | * Scoped controller. | * | * @author <a href="ales.justin(a)jboss.com">Ales Justin</a> | */ | public abstract class ScopedController extends AbstractController | { | private AbstractController underlyingController; | | public void setUnderlyingController(AbstractController underlyingController) | { | this.underlyingController = underlyingController; | } | | protected boolean isScoped() | { | return underlyingController != null; | } | | protected void addControllerContext(ControllerContext context) | { | if (isScoped()) | { | underlyingController.removeControllerContext(context); | context.setController(this); | registerControllerContext(context); | } | else | super.addControllerContext(context); | } | | protected void removeControllerContext(ControllerContext context) | { | if (isScoped()) | { | unregisterControllerContext(context); | context.setController(underlyingController); | underlyingController.addControllerContext(context); | } | else | super.removeControllerContext(context); | } | | } | It has protected methods, so that they can be accessed in ScopedKernelController. And AbstractController now has package protected methods: | void addControllerContext(ControllerContext context) | { | registerControllerContext(context); | } | | // TODO This api looks broken and unsafe see above | void removeControllerContext(ControllerContext context) | { | unregisterControllerContext(context); | } | Is this OK? Or too ugly hack? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072958#4072958 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072958

18 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Grouping of messages with JMSXGroupId(JBMESSAGING-375)

by aslak

How about adding support on the server for the JMSXGroupSeq as well. Ensuring that messages are delivered in sequence to the same consumer. Not sure what to do if they don't come in sequence,.. Maybe a TTL could handle it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072953#4072953 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072953

18 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portletbridge/web-clipping

by chris.laprun＠jboss.com

"cdelashmutt" wrote : After trying out the latest portletbridge (circa Jan 2007), I'm beginning to question the value of a full page in a portlet window. It seems to me that it might be more useful to simply clip a small part of a page. For instance, there is perhaps this table that you want to display, but you really don't need anything else. I agree that the full page clipping is not that useful as well for the general case. However, I see web clipping as being used mostly to integrate existing web apps into a portal environment. In this situation, retrieving the whole page would make sense. "cdelashmutt" wrote : Web Clipping in general has many challenges. Does it make sense to include CSS styling from the source? What about JavaScript? Personally, I'd rather the source strictly be used for data, and the portal styles should be applied to the content. It's difficult to tell in a generic way. This could potentially be done if the imported markup was semantically written but this is far from being the norm (e.g. how many times do you see tables used for laying out elements?). Also, even with semantic markup, it could be quite tricky to discard CSS styles as they could be used for things as progressive disclosure of elements in conjunction with javascript, hence leaving you with more content that you really should be rendering. "cdelashmutt" wrote : Specific to portletbridge, I tried to point it to Slashdot, which is what they seem to use for testing. In Portal 2.6, this causes the Renaissance theme to get corrupted. I don't know if this is a Portal problem or what, but it seems like the slashdot styles are leaking into Portal. The image and link HREF stuff does seem to be re-written properly, it's just that styling that is messed up. | | Strangely, portletbridge actually only seems to work properly with plan HTML. If I try to go to a site that claims to be XHTML, I start getting problems. For instance, I've tried to clip some stuff from a site running RT, and none of the link re-writing works. | | Is there any interest in this type of a feature? I thought I was interested, but I don't know if it even makes sense now. I think there is a huge interest but as you pointed out, there are also lots of problems. I am investigating things to see what can be done to improve the situation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072949#4072949 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072949

18 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Count Messages with Selector and Edit Message

by hendra_netm

Creating JIRA tasks: http://jira.jboss.com/jira/browse/JBMESSAGING-1045 http://jira.jboss.com/jira/browse/JBMESSAGING-1046 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072944#4072944 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072944

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - AbstractController add/removeControllerContext

by alesj

"adrian(a)jboss.org" wrote : | I note you've still not fixed some of the public methods you introduced | on the AbstractKernelController that I complained about before. | | They need fixing otherwise somebody can break the entire state machine with injudicious | (or malign) invocations on those methods. | | This is basic OO principles. All public methods should keep the invariant state | of the underlying Object, there should be no backdoors. :-) | Actually it's not AbstractKernelController, it's AbstractController, which complicates things - different package then ScopedKernelController - otherwise I could use package protected. :-( Looking at the code, I don't see how else I can move context from underlying controller into scoped one. Except for changing the whole impl, putting the scope information into base controller concept - which doesn't look that trivial to do. :-) Any ideas how to keep the current impl and at the same time remove this ugly public backdoors? e.g. ScopedKernelController extends AbstractKernelController extends ScopedController extends AbstractController And make those methods package protected? Too ugly and outside concept? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072939#4072939 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072939

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassCastException for char[] MetaValue creation

by alesj

"scott.stark(a)jboss.org" wrote : | Just drop the depth parameter. | Done. Removed 'depth' from getArrayClass and interface method getArrayType. Changed tests to use zero instead. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072929#4072929 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072929

18 years, 8 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 2007