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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: How does version.properties get copied

by clebert.suconic＠jboss.com

I will just keep the native version counter separated. That way I will only change the native version when we need to. That way the native library from JBM 2 GA would later work fine with JBM 2.1 GA as long as we didn't make any change on native. I guess this would be better since I don't expect many changes on the AIO native layer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168833#4168833 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168833

17 years, 4 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - JBAS-5673 - Metadata processing

by emuckenhuber

Looking into https://jira.jboss.org/jira/browse/JBAS-5673, i noticed that something is missing in the web annotation processing with injection targets. e.g. having 2 classes with the same EJB or Resource reference ends up in only one injection target for this reference: | public class FooServlet | { | @EJB(beanName="StatefulTestBean", beanInterface=StatefulIF.class) | private StatefulIF statefulTestBean; | } | public class Foo2Servlet | { | @EJB(beanName="StatefulTestBean", beanInterface=StatefulIF.class) | private StatefulIF statefulTestBean; | } | would result in a AnnotatedReferenceMetaData with one InjectionTarget, instead of two - which basically affects also @Resource, @PersistenceContext, @WebServiceRef processors. As it's currently done like (pseudocode): | AnnotatedEJBReferenceMetaData ref = createAnnotatedEJBRef(...); | ref.setInjectionTargets(injectionTargets); | refs.add(ref); | So i guess it should rather be something like: | AnnotatedEJBReferenceMetaData newRef = createAnnotatedEJBRef(...); | AnnotatedEJBReferenceMetaData existingRef = refs.get(newRef.getName()); | if(existingRef == null) | refs.add(ref); | else | mergeInjectionTargets(existingRef, newRef) | Or should this be done in a different way ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168828#4168828 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168828

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : | To make this work, you'd need something like the following (untested): | | | Index: src/main/org/jboss/deployers/vfs/deployer/kernel/BeanMetaDataDeployer.java | | =================================================================== | | --- src/main/org/jboss/deployers/vfs/deployer/kernel/BeanMetaDataDeployer.java (revision 76634) | | +++ src/main/org/jboss/deployers/vfs/deployer/kernel/BeanMetaDataDeployer.java (working copy) | | @@ -27,12 +27,14 @@ | | import org.jboss.beans.metadata.spi.ClassLoaderMetaData; | | import org.jboss.beans.metadata.spi.ValueMetaData; | | import org.jboss.dependency.spi.Controller; | | +import org.jboss.dependency.spi.ScopeInfo; | | import org.jboss.deployers.spi.DeploymentException; | | import org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer; | | import org.jboss.deployers.structure.spi.DeploymentUnit; | | import org.jboss.kernel.Kernel; | | import org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext; | | import org.jboss.kernel.spi.dependency.KernelControllerContext; | | +import org.jboss.metadata.spi.scope.ScopeKey; | | | | /** | | * BeanMetaDataDeployer.<p> | | @@ -108,6 +110,9 @@ | | } | | } | | KernelControllerContext context = new AbstractKernelControllerContext(null, deployment, null); | | + ScopeInfo scopeInfo = context.getScopeInfo(); | | + scopeInfo.setScope(unit.getScope()); | | + scopeInfo.setMutableScope(unit.getMutableScope()); | | try | | { | | controller.install(context); | | I tried modifying this to | KernelControllerContext context = new AbstractKernelControllerContext(null, deployment, null); | //Make sure that the metadata from the deployment gets put into the context | ScopeInfo scopeInfo = context.getScopeInfo(); | scopeInfo.setScope(unit.getScope()); | scopeInfo.setMutableScope(unit.getMutableScope()); | scopeInfo.addMetaData(controller.getKernel().getMetaDataRepository().getMetaDataRepository(), context); | but still do not see the required metadata from the deploymentunit View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168827#4168827 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168827

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: How does version.properties get copied

by timfox

I prefer having a real version.properties file (not generated), and build-messaging.xml can load those properties if it needs them from that file. During the build process we need to copy other files too e.g. jbm-connector-factories.properties, and it seems cleaner to me to just have them all as real files instead of some generated and some not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168822#4168822 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168822

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: How does version.properties get copied

by clebert.suconic＠jboss.com

I thought version.properties was being generated from build-messaging.xml, and it is actually committed. As I said before, it should be generated. For instance I'll later add some version control between the native and java layer. I will throw some errors if the native layer is on an older version than the java layer, but for that to work well it would be better to have a single point where the version is maintained, and I guess the best place for that is build-messaging.xml. Any counter opinion? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168816#4168816 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168816

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by kabir.khan＠jboss.com

Adrian's suggestion looks for JBDEPLOY-69 most like what I am after. Unfortunately, it does not do the job. While I get a metadata retrieval at APPLICATION scope, it is empty and does not have the metadata I put in. I'm pretty sure that is the way it works, but I've spent most of the day trying to get all the snapshots working in my local copy of AS, so I could be wrong. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168813#4168813 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168813

17 years, 4 months

1
0
0 / 0

[Design of Clustering on JBoss] - Service Binding Manager

by bstansberry＠jboss.com

Just an FYI for those who follow this forum re changes in Service Binding Manager. See http://wiki.jboss.org/wiki/AS5ServiceBindingManager as well as JIRA and forum thread linked from that page. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168805#4168805 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168805

17 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by bstansberry＠jboss.com

I'm not sure I completely understood Julien's comment, but yes, Prabhat, what you said sounds correct, since any portlet session replication feature is leveraging the standard HttpSession replication. Julien, please correct me if I'm wrong. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168798#4168798 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168798

17 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by prabhat.jha＠jboss.com

I think I did a good job of confusing Brian and it's my bad. I assumed that since portal has a cache definition, it would use it for all clustering configuration. So if I am not mistaken now, tree cache configuration change that I would do in jboss-web-cluster.sar would affect portal and portlet session replication. Changes that I have been doing in jboss-portal-ha.sar would only affect clustering related to hibernate. correct? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168795#4168795 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168795

17 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by julien＠jboss.com

About portlet replication: by default JBoss Portal does not do anything and portlet session are wrappers of HttpSession but of a *dispatched* session, quite often in a cross context manner. We have an internal replication mechanism which leverages the portal session (i.e the one we are sure it is replicated). To store portlet session state in the portal session to have the replication feature. So we don't do much magic as we use standard Servlet API and nothing else and everything we do seems to me valid. So bottom line, we can do portal replication and optionally we provide a replication for portlets that configures it. We don't use anything that is not Servlet API based and that is not exotic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168792#4168792 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168792

17 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2008