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

[Design of EJB 3.0] - Re: Validation of Complete EJB2.x Views: EJB3 or Metadata?

by wolfc

Some things can not be checked in metadata, because they require the correct class loader. For example whether a remote interface is really an interface and extends EJBObject. This is different for the annotation meta data creator, it has classes to work with. So it can do more checks. As a post condition it should not be allowed to create invalid meta data. I think the validations should be in jboss-metadata, but care must be taken that they should not be intertwined with code that performs a different function. In the end, somewhere in the deployer chain something like: Set<InvalidConstraint<JBossMetaData>> violations = someValidator.validate(jbossMetaData, "ejb3"); should occur. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152989#4152989 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152989

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: profile service, farming

by bstansberry＠jboss.com

Been digesting this for a bit. :) anonymous wrote : Synchronization of multiple local file based repositories as you describe is difficult for something outside of the profile service as the exact state of a deployment is the raw deployment content + any admin edits that may have occurred. Raw content sitting on the disk may not be in the profile depending on what removing a deployment from a profile actually does. I wasn't clear about one thing when I described that concept -- I was only thinking of that approach in terms of the basic.ProfileServiceImpl; i.e. an equivalent to VFSDeploymentScannerImpl that handles DeploymentPhase.APPLICATION_CLUSTERED. This is one reason I considered it low priority. It doesn't fit with the full profile service impl, which works differently. anonymous wrote : So 'hotdeployment' is purely a profile implementation detail, how we reconcile local repositories across a cluster would be part of the org.jboss.profileservice.spi.DeploymentRepository.getModifiedDeployments() implementation. This part isn't clear to me. I certainly see how keeping different repositories in sync across a cluster is a detail of the repository implementation. And I can see how a cluster-aware DeploymentRepository instance could somewhat control when a ProfileImpl is aware of a change; e.g. don't make the profile aware of the change until all the repository instances in the cluster are aware of it. But that doesn't get to controlling how the profile changes get reflected in the runtime. That's a task of the MainDeployer and the deployers. I'll talk about a specific ideal scenario: An ear is deployed on all 4 nodes of a cluster. New version of the ear is deployed. Goal is that the ear be brought to a certain deployment stage (DeploymentStages.REAL?) on all nodes in the cluster such that we know the deployment will work on all nodes. A 2PC "prepare". At that point a cluster-wide "commit" is executed, the deployments are brought to the final stage where they handle requests, and the old version is removed. If there is a failure during the "prepare", the new version is rolled back and the old version left in place. There can be other variations on the above, but the main point is there is a multistep deployment process that requires intra-cluster communication at various points. Who controls that process is my question -- doesn't seem like its a concern of the DeploymentRepository, also doesn't seem like a proper concern of a deployer. My last post mentioned "some variant of the HDScanner concept" but that's not it either; you're right, HDScanner is just a trivial link between the profile and the MainDeployer and shouldn't be made into something else. Seems like this is at least partly a concern of a cluster-aware MainDeployer. anonymous wrote : The simple notion of having a deployment available across all nodes in the cluster, the DeploymentPhase.APPLICATION_CLUSTERED notion of the DeploymentRepository. There could be an annotation for this down to a bean level rather than a coarse deployment level. We could support this using the MetaDataRepository levels and have a clustered MetaDataRepository where we just distributed the BeanMetaData(for example) for the annotated bean. Provided the deployers/deployment attachments were properly integrated with the MetaDataRepository, it should just work, but there is a dependency issue. This is the part I need to dig into more to get a better understanding of what you mean. Perhaps that will answer my question above. :) anonymous wrote : Cluster wide dependencies between beans. Dependencies on components that are marked as @Clustered needs a cluster aware dependency implementation. Custom dependencies are supported by the mc, but the component deployers generating the component metadata have to generate the correct dependency implementation. Good point. This will be a nice thing to have. This again has a coordination aspect; e.g. bean A on node 1 expresses a dependency on bean B that will be deployed on node2. If both A and B are known, cluster-wide, to the respository, you don't want A's deployment to fail with a missing dependency just because node 2's deployers haven't processed B yet. anonymous wrote : Clustering like security is a cross cutting notion that we need the proper metadata for, and hooks to which cluster aware variations of the aspects can be applied. Agreed. Right now the clustering metadata that exists is scattered, and it only exists for EJBs and web sessions. When I think in terms of priority order though, I'm thinking somewhat differently. To me, it's 1) Restoring some sort of ability to have repository information synchronized. This is really the only thing the old farming did, in a half-assed way ;). I'd like to have this for 5.0.0.GA as I don't like taking something away, even if was half-assed. 2) Sorting out the "coordination" issue I've been talking about. The lack of that kind of coordination IMHO has always been the biggest weakness in the old FarmService. 3) Cluster wide dependencies. This could be done earlier if our solution for 1) ensures, following my example, that node 2's ProfileImpl knows about bean B before node 1's ProfileImpl knows about bean A. 4) Adding cluster-aware aspects to beans other than the existing JEE ones. Includes refactoring existing JEE clustered aspect impls to use as much of a common code base as possible. Creating proper clustering metadata is an underlying task that occurs throughout the above. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152982#4152982 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152982

17 years, 7 months

1
0
0 / 0

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

by scott.stark＠jboss.org

See the latest api in the server trunk along with the org.jboss.test.profileservice.test.DeployUnitTestCase which has tests for deploying an ear, war, sar, and mbeans archive. Currently only the mcbeans archive has any content and illustrates the api basics: | public void testMCBeansDeployment() | throws Exception | { | URL contentURL = super.getDeployURL("testMCBeansDeployment.beans"); | | // Distribute the content | DeploymentManager mgtView = getDeploymentManager(); | DeploymentProgress progress = mgtView.distribute("testMCBeansDeployment.beans", DeploymentPhase.APPLICATION, contentURL); | progress.addProgressListener(this); | progress.run(); | DeploymentStatus status = progress.getDeploymentStatus(); | assertTrue("DeploymentStatus.isCompleted", status.isCompleted()); | // It should not be running yet | assertFalse("DeploymentStatus.isRunning", status.isRunning()); | assertFalse("DeploymentStatus.isFailed", status.isFailed()); | | // Now start the deployment | progress = mgtView.start("testMCBeansDeployment.beans", DeploymentPhase.APPLICATION); | progress.addProgressListener(this); | progress.run(); | status = progress.getDeploymentStatus(); | assertTrue("DeploymentStatus.isCompleted", status.isCompleted()); | assertTrue("DeploymentStatus.isRunning", status.isRunning()); | assertFalse("DeploymentStatus.isFailed", status.isFailed()); | } | The currently implementation does upload the content, but its being started by the hot deployment service behavior, so its not the two step process it should be. This api differs from the jsr88 javaee deployment manager in that the targets(servers) to which a deployment manager applies are implicit rather than explicit. Its also different in that you obtain the DeploymentManager interface from jndi which implies some type of running server. We probably need a DeploymentManagerFactory to allow for different modes of operation. Take a look at the api and let me know if it fits with the jon notions of profile content management. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152976#4152976 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152976

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: EAR structure mock scanning

by alesj

"alesj" wrote : | So, someone needs to explain me now what is the logic behind JEE annotations and how the modules are marked. | e.g. what annotations mark some type (OK, I know the EJB3 one's, but have no clue about the others) OK, I've added this mock kind of type matching. It will do :-), since it's not really about what you return, it's about how you do it - via annotations scanning. | private Integer determineType(VirtualFile archive) | { | ClassLoader classLoader = getClass().getClassLoader(); | GenericAnnotationResourceVisitor visitor = new GenericAnnotationResourceVisitor(classLoader); | ClassFilter included = null; | ClassFilter excluded = null; | ResourceFilter filter = org.jboss.classloading.spi.visitor.ClassFilter.INSTANCE; | VFSResourceVisitor.visit(new VirtualFile[]{archive}, included, excluded, classLoader, visitor, filter); | AnnotationEnvironment env = visitor.getEnv(); | | Integer ejbs = getType(env, Stateless.class, J2eeModuleMetaData.EJB); | if (ejbs != null) | { | // check some conflicts - e.g. no @Servlet, ...? | return ejbs; | } | | Integer services = getType(env, Service.class, J2eeModuleMetaData.SERVICE); | if (services != null) | { | // check some conflicts - e.g. no @Servlet, ...? | return services; | } | | Integer appc = getType(env, AppClient.class, J2eeModuleMetaData.CLIENT); | if (appc != null) | { | // check some conflicts - e.g. no @Servlet, ...? | return appc; | } | | Integer wars = getType(env, Servlet.class, J2eeModuleMetaData.WEB); | if (wars != null) | return wars; | | return null; | } | | private Integer getType(AnnotationEnvironment env, Class<? extends Annotation> annotation, int type) | { | Set<Class<?>> classes = env.classIsAnnotatedWith(annotation); | return (classes != null && classes.isEmpty() == false) ? type : null; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152929#4152929 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152929

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5

by kabir.khan＠jboss.com

"kabir.khan(a)jboss.com" wrote : Disabling the AnnotationMetaDataDeployer, I am able to run some basic tests In other words, interception happens View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152907#4152907 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152907

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5

by kabir.khan＠jboss.com

Disabling the AnnotationMetaDataDeployer, I am able to run some basic tests View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152905#4152905 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152905

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5

by kabir.khan＠jboss.com

I had the old AspectDeployer running, which explains why I was getting good results :-( Disabling the old POST_CLASSLOADER AspectDeployer, I get no interception. This seems to be because the AnnotationMetaDataDeployer running in the POST_CLASSLOADER stage loads all the classes before the aop metadata beans are deployed by the BeanMetaDataDeployer in the REAL stage. I will try disabling AnnotationMetaDataDeployer for the purposes of my tests. I assume the plan is for this to be upgraded to use Ales's javassist annotation parser? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152897#4152897 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152897

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Some observations on pinging and ponging

by ataylor

ok, I've disabled what's there for the time being. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152893#4152893 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152893

17 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - how to call a flex application from JBoss portal or from JSP

by dilipreddy

Hi, I want the information regarding JBossPortal, I want to call a flex application on JBossPortal, I think it will call through JSPs please help me regarding this issue My jsp page is: <%@ page contentType="text/html; charset=iso-8859-1" language="java" import="java.sql.*" errorPage="" %> <%@ taglib uri="FlexTagLib" prefix="mm" %> <mm:mxml source="Example2.mxml"/> and Example2.mxml is: <?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"> <mx:Label text="Welcome" fontSize="15" color="red"/> </mx:Application> and the web.xml.......is <?xml version="1.0"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <taglib-uri>FlexTagLib</taglib-uri> <taglib-location>/WEB-INF/lib/flex-bootstrap-jsp.jar</taglib-location> </web-app> Error I am getting is: javax.portlet.PortletException: org.apache.jasper.JasperException: Unable to initialize TldLocationsCache: java.util.zip.ZipException: invalid entry size (expected 573 but got 574 bytes) Message: org.apache.jasper.JasperException: Unable to initialize TldLocationsCache: java.util.zip.ZipException: invalid entry size (expected 573 but got 574 bytes) please help me regarding this: Thanks in advance, Regards, Dilip View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152861#4152861 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152861

17 years, 7 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: JBoss/Java API

by trustin

You are in the wrong forum. Please post your question here again: http://www.jboss.com/index.html?module=bb&op=viewforum&f=141 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152838#4152838 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152838

17 years, 7 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