May 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Profiler] - Re: Crash when stopping JbossProfiler 2.0.Beta 1

by pisce

Hi, my loader-repository conf is like this: <jboss-app> <loader-repository> seam.jboss.org:loader=<webapp name> </loader-repository> </jboss-app> application.xml looks like the following: <web-uri><webapp name>.war</web-uri> <context-root>/<webapp name></context-root> <webapp name>.jar jboss-seam.jar I don't know if you need some other info, please tell me if you do. And note that this happens only at the first or second attempt to stop the profiler, otherwise it never happens. When it fails, I can only make it work by restarting JBoss AS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151439#4151439 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151439

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - JBMICROCONT-288 - Invalid feature request and invalid protoc

by adrian＠jboss.org

PROTOCOL I don't know how you manage your projects, but in mine things get discussed and decided on BEFORE JIRA issues get raised. That way we can decide what is the best way to implement it (if it all) and which project it should be in. We certainly don't break the build with bogus tests that fail especially when there is no way we are going support the feature because it doesn't make sense. DO ONE THING WELL Basic facts: * The Microcontaner kernel is NOT serializable. * There can be many kernels liviing in the same JVM at the same time. * The MC couldn't care less about serialization, it isn't its job. * Serialization is not injection To make JBMICROCONT-288 work (which it can't do in general) would require two processes. 1) Some mechanism to regain the reference to the relevant MC kernel instance. i.e. probably some singleton mechanism or in general something more complicated 2) A hook to (re)inject references during deserialization This cannot work in general * As above, how do you know which kernel to use? In the appserver there's certainly a singleton you access by doing ServiceController.getKernel(); but that is a property of the host environment not a feature of the MC. * After deserialization you have two instances of the same bean. One registered and managed with the MC, the other not. Deserialization creates a whole new object * Beans will do things with the objects injected, e.g. register themselves in the injected object | public void setRegistry(Registry registry) | { | this.registry = registry; | } | | public void create() | { | registry.register(this); | } | | | In general they can do arbitrary things which would mean serialization/deserialzation | | would have to invoke the entire lifecyle. i.e. it would become like ejb passivation | | Which almost certainly isn't what you want. You don't want the service | | torn down because somebody wants to serailze the state. | | It's ok to do that for pooled EJB instances, but not for singleton services. | | | | My conclusion from this request would be; | | YOU'RE DOING SOMETHING WRONG | | What that is depends upon what your real feature request/requirements are, | | rather than what you wrongly think they are in JBMICROCONT-288 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151436#4151436 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151436

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Obtain Kernel from unspecified Context

by ALRubinger

I believe this has now graduated to a Developer's issue: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151409 Ideally POJOs should not depend on the MC API, and could have everything injected from any IoC Container. However, this introduces a precondition that all POJOs with dependencies on MC Beans are installed into the MC itself. In many cases, this is not possible. Additionally, there are cases in which a POJO cannot have the Kernel available to it - ie. any instance that's not created by the application developer. What are the fundamental arguments against the following construct: KernelRegistry registry = KernelRegistry.getRegistry(); // Singleton | | /* | * The Registry maintains a Map of all Kernels created under a key | * of some KernelContext | */ | | // Properties from somewhere, possibly jboss-mc.properties | KernelContext context = new KernelContext(); | // KernelContext context = new KernelContext(Properties); // Valid as well | | Kernel kernel = registry.getKernel(context); ? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151433#4151433 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151433

17 years, 10 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: profiler taking a long time to get stats on version 2.0

by jesper.pedersen

It's analyzing the classes that have been profiled. You can disable the different identity plugins - such as ejb, servlet and the others. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151396#4151396 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151396

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: migrating TransactionManager and Invokers to POJO

by adrian＠jboss.org

The JMX lifecycle is now tied to the POJO lifecycle. I've also removed the duplicate invocation of the lifecycle methods when the POJO doesn't implement ServiceMBeanSupport (which had been previously hacked to catch the problem). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151367#4151367 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151367

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Deploying Ears and Wars through ProfileService

by scott.stark＠jboss.org

This is in progress with an update to the api checked in under: https://svn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/deplo... I need to finish the prototype implementation before I can say the api is usable. That should be done by Monday. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151345#4151345 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151345

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Classloading and versioning

by alesj

Yeah, I though about it some more after my posts last night, and came to similar conclusions. I though it was more flexible, but like your clarification shows, that's the only way to do it. But thanks anyway for shedding some light on the subject. Basically, what I did, was what I was asking you in email - an example of some hacky classloading policy. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151333#4151333 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151333

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Lookup of EPR

by tfennelly

Hi there... you can use the LogicalEPR for this. With the LogicalEPR, you just set the Service name+category of the Service Endpoint to which faults are to be routed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151331#4151331 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151331

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Lookup of EPR

by justinwalsh

Hi, Simple question: I need to set the faultTo field of a message within a listener. How do you look up an EPR that is defined? Thanks, View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151327#4151327 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151327

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Classloading and versioning

by adrian＠jboss.org

"alesj" wrote : | Even if it would, why would that be a problem? | Shouldn't there be a way to tell that in-bundle usage is a black box, and scott's usage of ales is impl detail. | | Would then there be a way to get runtime CCE if something ales's was exposed through scott and used in foobar? | Or how do you detect this at deployment, exposing the possible conflict? The way to tell the classloader that they are shared and could conflict is by expressing the export. Once the package is exported anything that imports it could load it. Think about it... foo imports ales from acme1 foo imports scott from acme2 but acme1 also exports scott and acme2 exports ales The classloader can't make the assumptions you are trying to make. it doesn't know that ales and scott won't leak across the two different deployments. They are exported so it must assume that they will since importers must need the classes for a reason. If they are not exported, there's no consistency check required. The modules are assume to only use the classes as private implementation detail. Even if they were the same physical classes on disk (and defined as the same version) you'd get a CCE since the classes are loaded by different classloaders. The fundamental problem is caused by an incorrect modularisation. You want to version ales and scott independently so foo can choose them independently. But you've tied them into the same bundle making this impossible. There be no problem if there was an acme1-ales:1.0.0 acme1-scott:1.0.0 acme2-ales:3.0.0 acme2-scott:4.0.0 foo could then choose acme1-ales:1.0.0 and acme1-scott-4.0.0 as long as acme1-scott-4.0.0 doesn't need to make an incompatible decision on what version of ales to use (and vice versa). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151322#4151322 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151322

17 years, 10 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 May 2008