September 2007 - jboss-dev-forums

[Design of POJO Server] - Re: Unifying metadata

by scott.stark＠jboss.org

The first thing I'm doing today is moving all of the metadata with the existing duplication into the https://svn.jboss.org/repos/jbossas/projects/metadata/trunk/ project, and deleting the metadata from the jbossas projects. That will at least get a unified artifact on which the deployers depend. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085731#4085731 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085731

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - ProfileService/OBR repository

by scott.stark＠jboss.org

I just checked in a OSGi OBR like addition to the org.jboss.profileservice.spi.repository package. The interfaces in there mirror the OSGi OBR interfaces with two additions: 1. The RepositoryAdmin has an additional Repository getRepository(URI repository) throws Exception; method. 2. There is an extension of the Repository interface that allows for addition/removal and modification detection of Resources: | public interface MutableRepository extends Repository | { | /** */ | public enum ModifyStatus {ADDED, MODIFIED, REMOVED}; | | /** | * Add a resource to the repository. | * @param resource the resource to add | * @throws Exception thrown on any addition failure | */ | public void addResource(Resource resource) | throws Exception; | /** | * Remove a resource from the repository | * @param name the resource SYMBOLIC_NAME or ID | * @return the Resource that was removed if found, null otherwise. | * @throws Exception thrown on any remove failure | */ | public Resource removeResource(String name) | throws Exception; | /** | * Return a collection of resources that have been modified since | * the last call to this method. The returned resources contain | * a modifyStatus property of type ModifyStatus to indicate the | * type of change. | * | * @return The Resources that have been modified. | * @throws Exception | */ | public Collection<Resource> getModifiedResources() | throws Exception; | } | There are still a lot of issues to validate in terms of actually using an OBR implementation. The validation of the OBR like API is in the mapping class org.jboss.system.server.profileservice.repository.RepositoryAdminAdaptor. This maps the current org.jboss.profileservice.spi.DeploymentRepository spi onto the org.jboss.profileservice.spi.repository.RepositoryAdmin OBR like SPI. I'm going to look at using some form of the Felix 1.1 bundlerepository code(http://svn.apache.org/repos/asf/felix/trunk/bundlerepository/) for the next release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085728#4085728 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085728

18 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4717 - Problem with @JMX for clustering

by bstansberry＠jboss.com

Thanks for the heads-up on the WARN from flush. I'm not seeing that locally, but I checked and see it in the server logs on a hudson run. http://jira.jboss.com/jira/browse/JBAS-4734 Looking at org.jgroups.JChannelFactory.connect it's setting a (hardcoded) timeout of 3 secs for the flush to complete. I think such a short timeout will for sure be a problem on production systems when nodes join active clusters; I've taken that up w/ Bela on the jgroups dev list. But if it's happening on simple server starts, there's something else going on. Vladimir's checking it out. Re: the NPE, apparently I'm going blind, as my first pass at http://jira.jboss.com/jira/browse/JBAS-4728 did nothing and I missed it. :( This should be fixed now. It's unrelated to the earlier WARN. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085709#4085709 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085709

18 years, 6 months

1
0
0 / 0

[Design of JBoss Build System] - Re: warning: unmappable character for encoding UTF8

by scott.stark＠jboss.org

The warnings are expected due to inconsistent file encoding usage. The vm crash is a vm bug, so its an issue with the install on the build machine. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085700#4085700 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085700

18 years, 6 months

1
0
0 / 0

[Design of JCA on JBoss] - Resource adapter transaction timeout enforcement

by david.lloyd＠jboss.com

I'm working on the Remoting 3 implementation of XAResource and I'm trying to figure out if transaction timeouts are better enforced on the local or remote side. With JCA resource adapters, are the transaction timeouts typically enforced by the resource adapter (I assume using the Timer stuff), or is it standard practice to have the actual resource itself manage the timeout (the database or whatever you're connecting to)? Basically I'm trying to come up with any reason that the resource adapter would not just deal with timeouts itself. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085690#4085690 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085690

18 years, 6 months

1
0
0 / 0

[Design of JBoss Build System] - Re: warning: unmappable character for encoding UTF8

by pgier

I get the same warnings when I build, but it doesn't seem to cause any problems for me. Everything seems to still build ok. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085686#4085686 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085686

18 years, 6 months

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 : "kabir.khan(a)jboss.com" wrote : 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? | | When I created the "Module" class, I only anticipated it was an implementation detail | of the classloader dependencies so I didn't put it in the spi. | | Any use of it would be a "hack" until the proper scoped metadata solution is done. Are you saying "don't use it", or "use it and we'll retrofit an SPI"? :-) As far as I can tell I will need information from the ClassLoaderPolicy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085667#4085667 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085667

18 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployer ClassLoader dependencies and OSGi

by scott.stark＠jboss.org

Let's add this to the common core lib then as I have another duplicate impl in org.jboss.profileservice.spi.repository.Version. Something like: | package org.jboss.util.id; | | public interface VersionFactory | { | public Version parseVersion(String version); | public Version newVersion(int major, int minor, int micro, String qualifier); | public Version emptyVersion(); | } | | public class Version implements Comparable, Serializable | { | public int getMajor(); | public int getMinor(); | public int getMicro(); | public String getQualifier(); | public String toString(); | public int hashCode(); | public boolean equals(Object object); | public int compareTo(Object object); | } | Default osgi like implementations could be in org.jboss.util.id.osgi View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085666#4085666 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085666

18 years, 6 months

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 : | It's not work in progress, at least not yet. | I only added the deployments scope a week ago. | | I'd suggest you try it yourself with a mock test, e.g. write an aspect | that pushes the metadata from the advisor onto the stack and test it using | the aop proxy where you can pass in the metadata. I've created some simple tests on my machine emulating what I think will happen at deployer level. | public void testDomain() throws Exception | { | URL url = null; | Domain domain = null; | try | { | //Create our instance to be proxied before we start deploying stuff | TestIntercepted test = new TestIntercepted(); | | //Deployer creates metadata and populates that with the necessary domain | createAndPushMetaData(createScopedDomain("xxx")); | | //We get the domain out of the metadata and deploy into that | MetaData md = MetaDataStack.peek(); | domain = md.getMetaData(Domain.class); | assertNotNull(domain); | url = deploy("1", Thread.currentThread().getContextClassLoader(), domain); | | //create the proxy, the scoped manger is taken from the metadata stack | AOPProxyFactoryParameters params = new AOPProxyFactoryParameters(); | params.setTarget(test); | params.setMetaData(md); | | AOPProxyFactory factory = new GeneratedAOPProxyFactory(); | TestIntercepted proxy = (TestIntercepted)factory.createAdvisedProxy(params); | assertFalse(proxy.getClass() == TestIntercepted.class); | | TestInterceptor.intercepted = null; | proxy.doSomething(); | assertNotNull(TestInterceptor.intercepted); | assertEquals("First", TestInterceptor.intercepted); | } | finally | { | if (MetaDataStack.peek() != null) | { | MetaDataStack.pop(); | } | undeploy(url, domain); | } | } | | private ScopeKey createScope(String app, String dep) | { | ScopeKey result = ScopeKey.DEFAULT_SCOPE.clone(); | result.addScope(CommonLevels.APPLICATION, app); | result.addScope(CommonLevels.DEPLOYMENT, dep); | return result; | } | | private void createAndPushMetaData(Domain scopedDomain) | { | //Deployer creates Domain depending on classloader rules, and adds it to metadata for deployment | ScopeKey scopeKey = createScope("Test", scopedDomain.getDomainName()); | MutableMetaDataRepository repository = new BasicMetaDataRepository(); | MetaDataRetrieval retrieval = new MemoryMetaDataLoader(scopeKey); | repository.addMetaDataRetrieval(retrieval); | | if (scopedDomain != null) | { | ((MutableMetaData)retrieval).addMetaData(scopedDomain, Domain.class); | } | MetaData metadata = repository.getMetaData(scopeKey); | MetaDataStack.push(metadata); | } | | private Domain createScopedDomain(String name) | { | AspectManager manager = AspectManager.getTopLevelAspectManager(); | Domain scopedDomain = new Domain(manager, name, false); | return scopedDomain; | } | | I think I am missing a part in the metadata stuff. What I have pasted in above works fine for generating the proxies, but I don't see how this will work when doing weaving? What if there is no metadata on the stack? Or would that be a bug when running within JBoss. Alternatively, we would need something to map from the classloader passed in to AspectManager.translate() to the metadata, but that sounds suspiciously like a variation of what we have at the moment (classloader=>ScopedClassLoaderDomain)? The second part of this is that the metadata is currently only really used at weaving/advisor population time. i.e we use the metadata to get the domain, and the annotations etc. to be used for the bindings etc. I think you have in mind something for the same class to have different interceptor chains invoked depending on the MetaData on the stack? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085664#4085664 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085664

18 years, 6 months

1
0
0 / 0

[Design of JBoss Build System] - warning: unmappable character for encoding UTF8

by ambika

Hi, I am trying to build Jboss 4.2.0.GA on Linux Platform with following version of the java. java version "1.5.0_10" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode, sharing) I am getting following warnings, then its creating a file hs_err_pid4213.log by the java. I tried with /home/jbossjboss-eap-4.2-src/jboss-as/server/src/main/org/jboss/metadata/SessionMetaData.java:49: warning: unmappable character for encoding UTF8 * name of the session beanï¿½s web service interface ^ /home/jbossjboss-eap-4.2-src/jboss-as/server/src/main/org/jboss/naming/java/javaURLContextFactory.java:35: warning: unmappable character for encoding UTF8 * @author Rickard ï¿½berg ^ /home/jbossjboss-eap-4.2-src/jboss-as/server/src/main/org/jboss/proxy/ejb/EJBMetaDataImpl.java:36: warning: unmappable character for encoding UTF8 * @author Rickard ï¿½berg (rickard.oberg(a)telkel.com) ^ /home/jbossjboss-eap-4.2-src/jboss-as/server/src/main/org/jboss/web/ThreadPool.java:29: warning: unmappable character for encoding UTF8 * Rickard ï¿½berg ^ # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGBUS (0x7) at pc=0xb7759b43, pid=4213, tid=3086157504 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_10-b03 mixed mode, sharing) # Problematic frame: # C [libzip.so+0xbb43] # # An error report file with more information is saved as hs_err_pid4213.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # run: line 10: 4213 Aborted sh ./build.sh -verbose In Linux by default LANG=en_US.UTF-8, do we need to change anything about. Did anybody faced this problem? Thanks and Regards, Ambika View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085663#4085663 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085663

18 years, 6 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 September 2007