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

[Design of JBoss Remoting, Unified Invokers] - Re: access to tomcat jars for remoting

by tom.elrod＠jboss.com

Seems to me should be handled at the invoker level (i.e. UnifiedInvoker) and use a service like the org.jboss.web.WebService we currently have. The WebService actually looks fairly good to me to what is needed (i.e. downloading classes). Maybe add another configuration attribute for what type of class files can be downloaded (i.e. "com.acme.domain.*") and should be sufficient? Also, where is the client code for downloading classes from the WebService? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4015407#4015407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4015407

19 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: JBossretro

by pgier

I created a basic pom.xml for javassist. Should javassist be moved to jboss/jboss-javassist to make the naming more consistent with other projects? Or should we leave the name as javassist/javassist? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4015342#4015342 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4015342

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by scott.stark＠jboss.org

Yes, that is what I'm thinking. It just seems that actually going through the full aop process to add this specific lifecycle extension is more work than necessary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4015296#4015296 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4015296

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | Really what I'm suggesting is that the aop:xxx lifecycle elements populate the list of orthogonal behaviors that should be applied during that phase. Ok so the aop:xxx lifecycle callbacks would implictly define the pointcuts? I wasn't involved in the design of this part so we'll have see what Kabir thinks. But it would make sense from my point of view if you could add an action for deployment time processing without having to add an introduction into the POJO. e.g. @JMX or @JNDI on the target bean would lead to lifecycle events on the context but you don't have to go through the proxy at runtime (although I know at least for the pure AOP this was almost a no-op anyway :-). The other reason why this would be useful is because I want to have the ability to see the MBean in the JMX-console even when the target doesn't exist for the "on-demand" behaviour. e.g. You would still a skeleton MBean with a single operation to start it. I don't know how far Kabir got with this using an Introduction and a "hollow proxy"? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4015277#4015277 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4015277

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by scott.stark＠jboss.org

What I was thinking of is that the install/uninstall actions would be handled as orthogonal behaviors rather than a single chain. Nulling them out would be the same as removing the aspect. Really what I'm suggesting is that the aop:xxx lifecycle elements populate the list of orthogonal behaviors that should be applied during that phase. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4015236#4015236 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4015236

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : there should be an AOPInstallUnistallAction that pulls the the behaviors to apply from the metadata. | Doesn't that suffers from the same problem? e.g. What if somebody else wants to an XXXInstallUninstallAction as well as a the AOP one? In general the MC actions are defined by the person that installs the context so they can add/remove/override the actions. e.g. Think about the what we want to do in the profile service where we "null out" the instantiate/configure lifecycle actions. At least with the AOP introductions/advices you can define what they are in the AOP config. Of course, we could go to a more "fundamental" full AOP advice chain in the MC actions where you could add abritrary behaviour to the actions chosen by the person that created the context? But I think this would be even harder to configure since you don't really have a "target" on which you define pointcuts? That is unless the pointcuts were just the MC lifecycle events and we had some custom pointcut language to identify where the advices are applied. It does have the advantage that you don't need to wrap the target in a proxy just to add an introduction for deployment time (rather than runtime) behaviour performed during the MC lifecycle events. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4015229#4015229 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4015229

19 years, 1 month

1
0
0 / 0

[Design of JBoss Wiki] - Re: Installing Wiki Error. wikiService

by szimano

Please install "portal" instead of "default" :) Tomek View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4015225#4015225 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4015225

19 years, 1 month

1
0
0 / 0

[Design of JBoss Wiki] - Re: Installing Wiki Error. wikiService

by indyJones

Ok...i ran this... | | java -jar jems-installer-1.2.0.CR1.jar -installGroup default installpath"/path/to/jboss/jboss-4.0.5.GA" | | And I stll get same error about not finding the WikiService... Am I missing something? indy View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4015223#4015223 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4015223

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Scoped beans deployment

by adrian＠jboss.org

Are ok. I sort of agree but for a different reason. We might want people to be able to override the DescribeAction with custom actions but they don't necessarily want to overide the scoping which will just be a "do it' from the information in the BeanMetaData. I think pre-install would be a better name than scope for this action/state. i.e. It is here where we modify the context to move it to a different scope (controller). The later actions will then see context.getController() as the correct one according to the scope. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4015218#4015218 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4015218

19 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Scoped beans deployment

by alesj

"adrian(a)jboss.org" wrote : | Perhaps an even safer mechanism would be to leave the context | in the NOT_YET_INSTALLED state in the root kernel until the describe action | dependencies are satisifed. Then promote it to the scoped kernel | in the describe action? This means 'going' to DescribeAction twice? Or I don't see it how you are trying to do this ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4015204#4015204 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4015204

19 years, 1 month

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 February 2007