September 2007 - jboss-dev-forums

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by bill.burke＠jboss.com

There are 3 approaches to this I believe 1. Don't have a JNDI dependency, use real dependencies that can be figured out at the DESCRIBE phase. Advantages: A pure solution. Disadvantages: a) Every component will need to change to add supplies b) Doesn't work with non-JBoss components. Components we don't control. user will have to explicitly say, HEY don't have a dependency for this thing! c) Doesn't work with remote JNDI bindings d) This is an all-or-nothing improvement 2. If a component has a JNDI dependency, register a depends with the Kernel of that JNDI name. Add a JNDIRegistryPlugin to the kernel. Extend JBoss JNDI so that listener objects could register for event callbacks. A Bind/unbind listener could install/remove JNDI beans that resolve the dependency Advantages: a) Minimal impact to other components (like JCA, etc...) Disadvantages: a) Doesn't work with remote JNDI bindings 3. If a component has a JNDI dependency, register a depends with the Kernel of that JNDI name. create a background thread that pings JNDI for unresolved JNDI names. When it pops up install a JNDI bean, when it disappears uninstall it. Advantages: a) Works with any JNDI dependency b) minimal changes Disadvantages: a) Every EJB3 SFSB lookup creates a session :). We're covered locally because dependency layer should create a real hard dependency for @EJB. But remote? b) requires a background thread that could slow deployment. I like #2 the best combined with #3. #3 would be there to soley handle remote JNDI dependencies. The reason I want #2 is that it doesn't require changes to everything. #1 is really bad as the user may encounter an error and will not know about the extra metadata they need to provide. #2 may also be useful for other things beyond kernel dependencies. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081904#4081904 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081904

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep (Repost)

by scott.stark＠jboss.org

There is quite the torturous dependency graph in getting rid of the snapshots for the mc release. aop depends on jboss-container, so that need to be released to do the aop release. I'm working on getting non-snapshot releases of: jboss-common 2.2.1.GA (done) jboss-vfs 2.0.0.Beta4 (done) jboss-test 1.0.4.GA (done) javaee 5.0.0.Beta3 (done, and used by jboss5) integration 5.0.0.Beta3 (done, and used by jboss5) jboss-container 2.0.0.Beta4 jboss.aop 2.0.0.alpha6 Kabir, https://svn.jboss.org/repos/jbossas/projects/aop/tags/JBoss_AOP_2_0_0_alp...) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081756#4081756 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081756

17 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deployer order solely based on inputs/outputs now?

by bill.burke＠jboss.com

Ok, after talking to Ales I think i get it. There would be: EJBParserDeployer EJBDescribeDeployer EJBComponentDeployer So, if my EJBDescribeDeployer is part of the DESCRIBE stage, it should happen after EVERY DeploymentUnit has gone through Parsing, right? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081894#4081894 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081894

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by alesj

The way it's currently done, contexts that depend on something outside MC have no way of being notified that their external dependency is/was resolved. The context will move fwd the next time something is added to MC, but there is no API to simply ping the kernel. Perhaps a better approach with JNDI registry - if you have access to MC - is to install a bean into MC after the JNDI entry was added, where the bean would simply/only provide a supply with a JNDI name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081881#4081881 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081881

17 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Deployer order solely based on inputs/outputs now?

by bill.burke＠jboss.com

Is deployer order solely based on inputs/outputs now? If so I believe I have a serious problem. I don't think the current approach in the EJB3 container of creating DependencyItems and RegistryPlugins is going to work. The main reason is that the @EJB annotation (and ejb-ref XML metadata) is incomplete. It does not have enough information to correctly define the dependency. This is why there were two deployers: EJBRegistrationDeployer and EJBStage2Deployer. Registration was supposed to work first on all deployments before Stage2. Stage2 would be able to determine the "REAL" dependencies by searching for @EJB refs (and @PersistenceUnit refs for that matter) based on: 1. Look in the jar first for the reference 2. Look in the EAR 3. Look globally EE6 will complicate things further as EJB jars will be deployable within WARs. Do you see the problem I'm getting at? Since @EJB is incomplete, it could be possible for it to resolve to something it is not supposed to. Some links to WIKI or forum posts would be helpful. (and no adrian, google doesn't always work as you have to know what to search for). thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081875#4081875 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081875

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: BPEL deployment

by alex.guizar＠jboss.com

I submitted before previewing... here is the intended post. BPEL-275 is about deploying a WAR file to the server in a portable manner. The user must provide the following artifacts: A. The BPEL process B. WSDL interfaces: define the messages, port types, partner link types, properties and property aliases referenced in A. C. XML schemas: define the elements and types referenced in A and B. The following artifacts are eligible for automatic generation. The user may still want to provide them for finer control of the resulting J2EE port components. D. WSDL endpoints: define the bindings, services and ports for the port types in B. E. bpel-application.xml: specifies the association between partner links in A and the services and ports in D. H. jaxrpc-mapping.xml: maps the bindings in D and the port types in B to service endpoint interfaces, plus the elements and types in C to to Java value classes. F. web.xml: lists the service implementation beans to be published as servlets. G. webservices.xml: links the ports in D to the servlets in F and the service endpoint interfaces in H. In the former model A-C were packaged in a process archive on the client and deployed to the jBPM database on the server. E-G were provided by the user. D and H were generated on the client. B-G were packaged in a WAR on the client and deployed to the server. The new model is yet to be defined. Now that E-G can be generated, how to provide custom artifacts becomes an issue. I have two approaches in mind: The client packages A, B and C and any overrides for E-G in a process archive and submits it to the server. The server generates any missing artifacts, builds the WAR and deploys it internally. Upon restart, the server is able to rebuild the WAR because the overrides are stored with the process definition. The client packages A, B and C in a process archive and submits it to the server. The client generates any missing artifacts, builds the WAR and deploys it to the server. Upon server restart, the server is not able to rebuild the WAR, hence it must not be deleted. My current preference is 1, although I have not figured out the file system access issues on the server. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081867#4081867 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081867

17 years, 1 month

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP asintegration WITHOUT the integration :-)

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : "adrian(a)jboss.org" wrote : | | My preferred solution to use the scopes. i.e. you can choose | | to deploy aop config at the SERVER, SUBSYSTEM, APPLICATION level, etc. | | but this requires doing a lot work fixing everything to make sure | | it sets the correct thread local MetaData for AOP to know which Scope | | applies at runtime. | | | | This thead local is really just a generalization of ejbs/mbeans | setting the correct context classloader and java:/comp/env | | In principle once this is done. The only work required by AOP | would be for the deployer to create hierarchical ... | Is this work in progress? Or please let me know how I can help make this happen. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081865#4081865 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081865

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: BPEL deployment

by alex.guizar＠jboss.com

BPEL-275 is about deploying a WAR file to the server in a portable manner. The user must provide the following artifacts: A. The BPEL process B. WSDL definitions containing the messages, port types, partner link types, properties and property aliases referenced in A. C. XML schemas containing the elements and types referenced in A and B. The following artifacts are eligible for automatic generation. The user may still want to provide them for finer control of the resulting J2EE port components. D. WSDL definitions containing the bindings, services and ports for the port types in B. E. The descriptor bpel-application.xml that specifies the association between partner links in A and the services and ports in D. H. The descriptor jaxrpc-mapping.xml that maps the bindings in D and the port types in B to service endpoint interfaces, plus the elements and types in C to to Java value classes. F. The descriptor web.xml that lists the service implementation beans to be published as servlets. G. The descriptor webservices.xml that links the ports in D to the servlets in F and the service endpoint interfaces in H. In the former model A-C were packaged in a process archive on the client and deployed to the jBPM database on the server. E-G were provided by the user. D and H were generated on the client. B-G were packaged in a WAR on the client and deployed to the server. The new model is yet to be defined. Now that E-G can be generated, how to provide custom artifacts becomes an issue. I have two approaches in mind: 1. The client packages A, B and C and any overrides for E-G in a process archive and submits it to the server. The server generates any missing artifacts, builds the WAR and deploys it internally. Upon restart, the server is able to rebuild the WAR because the overrides are stored with the process definition. 2. The client packages A, B and C in a process archive and submits it to the server. The client generates any missing artifacts, builds the WAR and deploys it to the server. Upon server restart, the server is not able to rebuild the WAR, hence it must not be deleted. My current preference is 1, although I have not figured out the file system access issues on the server. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081864#4081864 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081864

17 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: Cannot release javaee project

by scott.stark＠jboss.org

I'm doing it manually for now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081863#4081863 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081863

17 years, 1 month

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP asintegration WITHOUT the integration :-)

by kabir.khan＠jboss.com

Since Module is in the deployers-impl package I assume I should not use that from my AspectDeployer? I don't see any other way to get hold of of the information from ClassLoaderPolicy? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081862#4081862 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081862

17 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2007