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

[Design of POJO Server] - Re: Deployers in AS

by ALRubinger

"adrian(a)jboss.org" wrote : The parsing available in the metadata project (from ejb-jar.xml and jboss.xml) | should be enough to write your tests (using the same hooks that the deployers | use to create the real objects). | You don't care how the EJBMetaData gets constructed, that is a policy decision of the | appserver. e.g. parsing annotations, programmatically or something else. This assumes that EJB3 is intended for use only within the AS Environment. The Deployers in question need be an integration point only between jboss-metadata/MC and ejb3/MC, not AS. If I want to start up an Embedded or Standalone EJB3 Environment, I should be able to use the same Deployers, as they depend only on the MC Deployment API and other dependencies of EJB3. "adrian(a)jboss.org" wrote : The individual projects should not depend upon the appserver's deployers | or even the deployment api. | Use case: If I want to re-use ejb3 programmatically I should just be | able to instantiate the ejb3 metadata and make some call to a factory in the ejb3 | project. The EJB3 Components should not depend on the Deployers, true. Only metadata, and I'm doing a refactoring effort now to create Containers from only the metadata objects. The end result will eventually make programmatic creation of an EJB possible. However, an Assembly of EJB3 Standalone/Embedded should be able to re-use the same Deployers used in AS. That way, we don't have to create the metadata on our own by duplicating the logic already written. "adrian(a)jboss.org" wrote : Deployer and runtime configuration is a policy decision of the appserver. | If I want to swap out, augment or otherwise change how EJBMetaData gets | constructed that is something that is done in the integration project i.e. the AS. AS is not the only target integration project. So configuration is a policy decision of whatever is providing the runtime, and this is achieved by editing the ejb3-deployers-beans.xml file accordingly. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151475#4151475 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151475

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - profile service, farming

by scott.stark＠jboss.org

In going through the work to add arbitrary deployment content via the ManagementView of the profile service, it seems I should add an APPLICATION_CLUSTERED phase: | /** The class of deployment */ | public enum DeploymentPhase { | /** A deployment loaded during the server bootstrap phase */ | BOOTSTRAP, | /** An mc/service deployment for a Deployer to be loaded after the BOOTSTRAP phase */ | DEPLOYER, | /** Any deployment content to be loaded after the DEPLOYER phase */ | APPLICATION, | /** Any deployment content to be loaded across a 'cluster' after the APPLICATION phase */ | APPLICATION_CLUSTERED, | }; | I need such a notion to properly expose what targets would be part of the APPLICATION_CLUSTERED, and this also gets to the issue of not having a farming type service available in jboss5. I'm going to add this phase and start looking at what the implications are for the DeploymentRepository spi that describes the contents of a profile. This is work going on as part of JBAS-5370. I imagine we'll need to make some changes to properly support a clustered app notion so I'll create another jira for that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151467#4151467 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151467

17 years, 10 months

1
0
0 / 0

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

by ALRubinger

"adrian(a)jboss.org" wrote : * An invalid assumption in your argument | anonymous wrote : | | 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. | | | | There are at least four ways to inject objects that are not managed by the MC. No, I need to inject *into* a bean not managed by MC. I'll proceed for now by letting the Host environment maintain a reference to the Kernel, as you'd suggested. My stance is that it's not always possible to do pure IoC. Seems like you object to my use of MC as an Object Store * JNDI ObjectFactory.getObjectInstance() < Creates new instance of the Object Factory on every lookup * Struts Action Handler * Servlet * Anything else not instantiated by the developer S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151463#4151463 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151463

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: JBMICROCONT-288 - Invalid feature request and invalid pr

by adrian＠jboss.org

"wolfc" wrote : | In actuality I should create a seriailizable object which has both the serializable kernel reference and the name of the service I want to invoke upon. Then after deserialization I can invoke that service via the kernel bus. | | But I would still need a serializable kernel reference to be able to do that. | | Maybe a KernelReferenceRegistry which functions similar to the NonSerializableFactory? So I can do KernelReferenceRegistry.getKernelReference(kernel)? But then why not make the Kernel externalizable with it's own lookup map? Because people will (ab)use it (see Al's post in the MC forum). I don't understand why you need to "serialize" a reference to the KernelBus so I can't explain what you are doing wrong. One of my laws of programming/debugging; "Don't confuse the user's chosen solution with the problem" View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151450#4151450 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151450

17 years, 10 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Instructions for use with JBoss 3.2.6 ?

by jesper.pedersen

I took a quick look at the 3.2.8.SP1 release. You'll need to get JBoss Remoting up and running on that release since it isn't included. Otherwise you can't connect remotely. You don't need to add anything to the classpath as the JARs reference each other from inside the MANIFEST.MF files. You modify the jboss-profiler.properties on the server where you need to profile. You then use the client to connect to that server using the -h and -p arguments. The client is run from the directory where you unpacked the distribution. I think that it would be quicker to get the JBoss Profiler 1.0-CR4 release up and running on your platform. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151447#4151447 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151447

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Virtual File semantics exist in TomcatDeployment

by anil.saldhana＠jboss.com

"alesj" wrote : "anil.saldhana(a)jboss.com" wrote : We have Virtual File semantics still existing in TomcatDeployment. There has been a new introduction of a concept of "UnifiedVirtualFile" from the webservices component just to make a serviceref to WS. | What does this 'UVF' do? | | "anil.saldhana(a)jboss.com" wrote : | | At least the web services introduction seems wrong to me assuming that the tomcat usage of VFS semantics is a work in progress. | What is the status of this work then? | I don't seem to remember any post on this topis for a while now. | Are we done with what Adrian describes here? | - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150666#4150666 I am just reporting what I saw with TomcatDeployment [1]. I do not know what UVF does. I see that the VFS semantics is leaking into the metadata layer also (ServiceRefHandler) References: 1. http://anonsvn.jboss.org/repos/jbossas/trunk/tomcat/src/main/org/jboss/we... 2. | // Bind <service-ref> elements | UnifiedVirtualFile vfsRoot = new VirtualFileAdaptor(unit.getRoot()); | ServiceReferencesMetaData serviceRefs = metaData.getServiceReferences(); | if (serviceRefs != null) | { | for (ServiceReferenceMetaData sref : serviceRefs) | { | String refName = sref.getServiceRefName(); | new ServiceReferenceHandler().bindServiceRef(envCtx, refName, vfsRoot, loader, sref); | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151446#4151446 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151446

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Obtain Kernel from unspecified Context (Repost)

by adrian＠jboss.org

"ALRubinger" wrote : | What are the fundamental arguments against the following construct: | * Security - if you have two kernels in the same JVM with an api to get access to both, how do you stop one user playing with the other user's kernel? * API - why is name appropriate? e.g. for scoped kernels we use a scope key since the kernels are not independent and have a structure * An invalid assumption in your argument anonymous wrote : | 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. | There are at least four ways to inject objects that are not managed by the MC. 1) Using a factory (the factory knows how to get a reference to the object and it is then registered in the MC) 2) Using a value-factory (a more general approach where the object is not registered in the MC - e.g. this can be used to inject things like system properties or get information from an ldap server, etc. 3) Inject a locator - this is like (2) but less declartive. You inject an object that can be used to locate the relevant object in some arbitrary way 4) Using a KernelRegistryPlugin - maps some other "namespace"s into the MC injection namespace * Philosophy This isn't pure IOC. You now depend upon the API and not just that, you have to agree a name which probably isn't going to work in some arbitrary environment. e.g. look at the horrible hack where we locate the MBeanServer by seeing which has a default domain of "jboss" - which isn't even necessarily unique The kernel is only really required for specialised cases where some component wants to manage the state of another component. e.g. the service controller managing jmx lifecycle or the deployers managing the deployment lifecycle Other uses are generally hacks because you haven't thought out how to do IOC properly. * Summary In general the building of such a registry is something a user can do according their usecase. e.g. in the appserver the singleton kernel can be located using ServiceController.getKernel(). But there's nothing to stop a web-app creating its own kernel for its own internal use. The retrieval/availablity of the relevant kernel(s) is best left whoever created it, since only they know how it should be used. But this is really for "super users", most users should use plain IOC. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151442#4151442 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151442

17 years, 10 months

1
0
0 / 0

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

by adrian＠jboss.org

"ALRubinger" wrote : | What are the fundamental arguments against the following construct: | * Security - if you have two kernels in the same JVM with an api to get access to both, how do you stop one user playing with the other user's kernel? * API - why is name appropriate? e.g. for scoped kernels we use a scope key since the kernels are not independent and have a structure * An invalid assumption in your argument anonymous wrote : | 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. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151442#4151442 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151442

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: JBMICROCONT-288 - Invalid feature request and invalid pr

by wolfc

I agree, the test is wrong in the fact that it serializes a MC bean. Yes there can be multiple kernels within one VM, that still does not preclude a serializable reference to one particular kernel. In actuality I should create a seriailizable object which has both the serializable kernel reference and the name of the service I want to invoke upon. Then after deserialization I can invoke that service via the kernel bus. But I would still need a serializable kernel reference to be able to do that. Maybe a KernelReferenceRegistry which functions similar to the NonSerializableFactory? So I can do KernelReferenceRegistry.getKernelReference(kernel)? But then why not make the Kernel externalizable with it's own lookup map? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151441#4151441 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151441

17 years, 10 months

1
0
0 / 0

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

by pisce

Seems like I can't edit my post... here's the real application.xml <display-name>*webapp name*</display-name> | | <module> | <web> | <web-uri>*webapp name*.war</web-uri> | <context-root>/*webapp name*</context-root> | </web> | </module> | | <module> | <ejb>*webapp name*.jar</ejb> | </module> | | <module> | <ejb>jboss-seam.jar</ejb> | </module> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151440#4151440 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151440

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