January 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: serializable KernelDeployment

by adrian＠jboss.org

Jira issue for property replacement: http://jira.jboss.com/jira/browse/JBMICROCONT-143 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005224#4005224 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005224

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: serializable KernelDeployment

by adrian＠jboss.org

The property replacement during the parsing is coming from JBossXB. This is redundant since the microcontainer does do property replacement during the setter, see ValueConvertor.convertValue() invoked indirectly from the StringValueMetaData. To turn off the JBossXB processing we need to change the schema bindings: e.g. in BeanSchemaBinding20 public static void init(SchemaBinding schemaBinding) { + schemaBinding.setReplacePropertyRefs(false); initDeployment(schemaBinding); initBean(schemaBinding); initBeanFactory(schemaBinding); initArtifacts(schemaBinding); } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005222#4005222 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005222

19 years, 2 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Where can I find a list of what OS tomcat works whit?

by jfrederic.clere＠jboss.com

Tomcat uses JAVA so it needs a JVM and it runs on any OS that has a decent JVM. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005221#4005221 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005221

19 years, 2 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Where can I find a list of what OS tomcat works whit?

by civimagr

I'm interested too. Have you get it something? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005215#4005215 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005215

19 years, 2 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: Debug support for Serialization

by dustismo

Has anyone found a solution to this problem? I am getting the same exceptions and haven't found a solution. Every class in my app is serializable and has a default constructor. using jboss 4.0.5.GA and seam 1.1.1 thanks Dustin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005079#4005079 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005079

19 years, 2 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Atomic Operations

by akrishmohan

Hi I have a scenario in which I need to treat DB commit of 2 rows as one atomic operation. How do I achieve this using CMT? Any tips would be useful. Basically I have something like this. public class TestMDBean implements MessageListener { @PersistenceContext private EntityManagerFactory emf; @UserTransaction utx; private UserTransaction utx; private void updateLog() { //populate a pojo entity here in a collection. The collection has 2 objects corresponding to the two rows in the table. Roll back if a single commit fails. } I am not sure what kind of transaction strategy I need to use here. Let me know Cheers K View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005072#4005072 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005072

19 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-615 still present in Embedded-ALPHA9

by jazir1979

Hi Bill, We've gone and checked out the latest embedded stuff and built it from SVN. FYI, it worked well and was not very hard to convert our tests over to use the new Bootstrap class. However, we are getting exactly the same security problem still. Instead of a NullPointerException in Util.getSubjectRoles(), we get the IllegalArgumentException because this class has been updated to check for null. Here is our stacktrace: | java.lang.IllegalArgumentException: Subject is null | at org.jboss.security.Util.getSubjectRoles(Util.java:632) | at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:302) | at org.jboss.security.plugins.JBossAuthorizationManager.doesUserHaveRole(JBossAuthorizationManager.java:126) | at org.jboss.security.plugins.JaasSecurityManager.doesUserHaveRole(JaasSecurityManager.java:401) | at org.jboss.ejb3.BaseSessionContext.isCallerInRole(BaseSessionContext.java:233) | ..... | Would you like me to update JIRA to show that this bug is also present in the latest code based on JBoss5? thanks, daniel. "bill.burke(a)jboss.com" wrote : We've totally scrapped Embedded EJB3 and started the Embedded JBoss project based on JBoss 5 kernel. New Embedded JBoss will be full featured. Most features of regular jboss should be available in embedded. | | If you want to testdrive, checkout head SVN. its in the jboss-head/embedded directory. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005051#4005051 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005051

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: DataSource/ServiceXSLDeployer processing issue

by weston.price＠jboss.com

Yeah, so I guess you indirectly understand what I was trying to tell you about 2 months ago ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005042#4005042 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005042

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: DataSource/ServiceXSLDeployer processing issue

by scott.stark＠jboss.org

Two related issues in terms of the profile service being able to run a deployment through all deployers to avoid having to make assumptions about at what level the metadata that can be edited is available. The first is that the kernel lifecycle actions need to be stubbed out to be noops to avoid any actual beans being created. When the profile service is in the server, how can this be done? This also requires separate notions of transient attachments as already requested by Bill. There should be attachments that are candiates for overrides and saving/serialization and those that are not. I think we need a terminology reorg so that: - transient attachments are metadata that are not serialized or candiates for overriding by admin ManagedObjects. - attachments are metadata that can be serialized and overriden by admin ManagedObjects. - managed objects are metadata overrides of the attachments metadata. A Deployer that uses transient attachments would need to check for these and recreate these from the attachment and other input as needed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005038#4005038 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005038

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - DataSource/ServiceXSLDeployer processing issue

by scott.stark＠jboss.org

A problem I ran into while trying to implement the CRUD usecases for *-ds.xml deployments is that the metadata representation of a datasource deployment should be a ServiceDeployment with a xml dom representation of the *-ds.xml deployment. It currently is a ServiceDeployment with a xml dom representation of the transformed *-service.xml containing the jca mbeans. The two problems that exist are: 1. the profile service only wants to rerun the deployment processing from the Deployer.CLASSLOADER_DEPLOYER on to avoid duplicate metadata parsing and overwriting of the overriden attachment metadata coming from the ManagedObject updates. However, for a datasource deployment, the xsl transform occurrs during the parsing phase. The datasource deployment therefore would need to be run through the parsing deployers. 2. the datasource deployment does not have a valid representation of the *-ds.xml metadata. There is no xml dom view of the original *-ds.xml that can be updated via ManagedObject/ManagedProperty bindings. The xsl transform always goes to the *-ds.xml VirtualFile and applies the transform to the dom that results from parsing it. The general issues are deployers not having overridable metadata representations, and not knowing where to start the parsing. The latter issue is really more of not being able to simply rerun all deployers and only have those which have work to do function. I view this is an issue with not having the DeploymentUnit attachments api sufficiently well defined. As a review, here is the current state of the attachments api and its meaning. Deployers deal with DeploymentUnits as the view on a deployable unit of work. There are two types of DeploymentUnits, containers which can top-level deployments (ears, ejb-jars, wars, sars, -beans.xml, ...), and components which belong to a container deployment (ejbs, mbeans, mc beans, servlets, ...). Components are associated with their container via DeploymentUnit.addComponent(String). Container type deployment can be nested structurally as well, but the DeploymentUnit does not currently expose an api for accessing this. Its a todo. Metadata can be associated with a DeploymentUnit. This is done using the Attachments api. There are a few different levels of Attachments. A DeploymentUnit is an extension of the Attachments api. A DeploymentUnit also has an Attachments accessed via getTransientManagedObjects(). Adding an attachment via addAttachment adds a transient attachment. To add a transient managed object attachment, call getTransientManagedObjects().addAttachment. The difference between a transient attachment and transient managed object attachment is that transient managed object attachments are overrides to transient attachments. When you call the DeploymentUnit.getAttachment(), the implementation first looks for a transient managed object attachment override. If that is not found, then the transient attachments are consulted. Deployers should only populate the transient attachments while admin interfaces like the profile service populate the transient managed object attachments. One should be able to run a deployment trough the deployers, and then re-run the resulting DeploymentUnit through again and have this essentially be a noop in terms of the creation of metadata attachments as a Deployer should look for an existing attachment and avoid recreating it from the deployment content. One area which this is broken is when more than one parsing deployer populates the same metadata model from multiple sources. This happens for standard descriptors/annotations that can be augmented/overriden by jboss descriptors/annotations. With the addition of the DeploymentUnit Set getTypes(), the check for whether parsing should be done in the case of shared metadata attachments could be whether the attachments exist, and the DeploymentUnit has been marked as being of the curent Deployer.getType(). For the datasource deployment issue, the XSL deployers still need to support a dom attachment that represents the pre-transformed xml model so that it can be overriden. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005030#4005030 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005030

19 years, 2 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 January 2007