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

[Design of JBoss Build System] - Where is the stax:stax-api artifact is coming from

by scott.stark＠jboss.org

I don't see where this jbossas/thirdparty/pom.xml stax:stax-api artifact is coming from: | <dependency> | <groupId>stax</groupId> | <artifactId>stax-api</artifactId> | <mapping> | <componentId>stax-api</componentId> | </mapping> | </dependency> | Its not under http://repository.jboss.org/maven2/. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169349#4169349 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169349

17 years, 8 months

1
0
0 / 0

[Design of JBoss Build System] - Re: jboss.jbossts:resources:jar:4.4.0.CR1 warning in jbossas

by pgier

Looks like I missed some cases when working on JBBUILD-481. It should be fixed now in the new snapshot of the buildmagic-thirdparty maven plugin. You can get the new snapshot using mvn -up package >From the thirdparty directory. Otherwise, the build should automatically get the new plugin version tomorrow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169347#4169347 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169347

17 years, 8 months

1
0
0 / 0

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

by kabir.khan＠jboss.com

After a few false starts, I now see that the MDR used by DescribeAction is the same as the one that I push the correct AspectManager to use to. However, the wrong metadata is got at the DescribeAction stage. I've traced through, and will describe what is happening. Hopefully someone more familiar with the MDR can shed some light, since I am not 100% sure how this should work. My code for pushing the AspectManager is | private String registerScopedManagerBean(int sequence, VFSDeploymentUnit unit, AspectManager scopedManager, AopMetaDataDeployerOutput output) throws DeploymentException | { | unit.getMutableMetaData().addMetaData(scopedManager, AspectManager.class); | } | The mutable scope key used underneath is | [APPLICATION=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar] | When deploying the beans, I use the suggested | private void deploy(DeploymentUnit unit, BeanMetaData deployment) throws DeploymentException | { | ... | 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()); | ... | } | as mentioned here http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168986#4168986 the call to | scopedInfo.setScopeInfo(unit.getScope()) | in BeanMetaDataDeployer changes the scopeInfo.scopeKey from | [JVM=THIS, CLASS=org.jboss.beans.metadata.plugins.factory.GenericBeanFactory, INSTANCE=ScopedAlias_13_Factory$ScopedInterceptor, WORK=5644960] | to | [JVM=THIS, APPLICATION=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar, DEPLOYMENT=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar] | Should they not be merged to something like the following? | [JVM=THIS, APPLICATION=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar, DEPLOYMENT=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar, CLASS=org.jboss.beans.metadata.plugins.factory.GenericBeanFactory, INSTANCE=ScopedAlias_13_Factory$ScopedInterceptor, WORK=5644960] | Also, the call to scopeInfo.setMutableScope changes the scopeInfo.mutableScopeKey from | [INSTANCE=ScopedAlias_13_Factory$ScopedInterceptor] | to | [APPLICATION=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar] | As part of PreInstallAction, AbstractScopeInfo.addMetaData() adds a new MemoryMetaDataLoader under: | [APPLICATION=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar] | with this code | public void addMetaData(MutableMetaDataRepository repository, ControllerContext context) | { | this.repository = repository; | ScopeKey scope = getMutableScope(); | MemoryMetaDataLoader mutable = new MemoryMetaDataLoader(scope); | repository.addMetaDataRetrieval(mutable); | addMetaData(repository, context, mutable); | } | This happens for every bean, and it overwrites the existing MetaDataContext that contained the aspect manager to use, so this no longer exists in the repository. Should this check if a retrieval exists already, and add to that instead? I also noticed, that in DescribeAction it obtains the metadata using the context's scope | [JVM=THIS, APPLICATION=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar, DEPLOYMENT=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar] | This returns a MetaDataRetrieval containing retrievals with the following scope keys | [DEPLOYMENT=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar] | [APPLICATION=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar] | [JVM=THIS] | Are CLASS and INSTANCE missing due to the change when calling scopedInfo.setScopeInfo(unit.getScope())? Inspecting this a bit further, the MetaDataRetrieval at APPLICATION level is not the same as the one stored under | [APPLICATION=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar] | What is/should the link be between the two? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169341#4169341 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169341

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: managementService.registerQueue call on JournalStorageMa

by jmesnil

you're right: i'd be better moved to move it to the PostOffice. I'll fix it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169339#4169339 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169339

17 years, 8 months

1
0
0 / 0

[Design of JBossXB] - JAXB api dependency

by scott.stark＠jboss.org

https://jira.jboss.org/jira/browse/JBXB-149, we are depending on: | <dependency> | <groupId>javax.xml.bind</groupId> | <artifactId>jaxb-api</artifactId> | <version>2.1</version> | <scope>compile</scope> | </dependency> | but we are validating as part of the jbossas tck: | <dependency> | <groupId>sun-jaxb</groupId> | <artifactId>jaxb-api</artifactId> | <version>2.1.4</version> | </dependency> | We need to update this to sun-jaxb:jaxb-api to be consistent. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169335#4169335 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169335

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - managementService.registerQueue call on JournalStorageManage

by clebert.suconic＠jboss.com

On the latest change done by Jeff Mesnil on the management API, it was added a managementService call to register the Queue during loadBindings. Shouldn't that be done by the PostOffice? The JournalStorageManager doesn't seem qualified to IMO. Maybe: private void loadBindings() throws Exception | { | List<Binding> bindings = new ArrayList<Binding>(); | | List<SimpleString> dests = new ArrayList<SimpleString>(); | | storageManager.loadBindings(queueFactory, bindings, dests); | | | | for (Binding binding: bindings) | { | managementService.registerQueue(bindings...blablabla); | } | | | //Destinations must be added first to ensure flow controllers exist before queues are created | for (SimpleString destination: dests) | { | addDestination(destination, false); | } | | Map<Long, Queue> queues = new HashMap<Long, Queue>(); | | for (Binding binding: bindings) | { | addBindingInMemory(binding); | | queues.put(binding.getQueue().getPersistenceID(), binding.getQueue()); | } | | storageManager.loadMessages(this, queues); | } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169328#4169328 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169328

17 years, 8 months

1
0
0 / 0

[Design of JBoss Build System] - jboss.jbossts:resources:jar:4.4.0.CR1 warning in jbossas thi

by scott.stark＠jboss.org

Some code in the thirdparty setup appears to be trying to access thirdparty/jboss/jbossts/resources as a regular file when its a directory: | [WARNING] Unable to extract resources artifact: jboss.jbossts:resources:jar:4.4.0.CR1:compile | [WARNING] | java.io.FileNotFoundException: /Users/svn/JBossHead/jboss-head/thirdparty/jboss/jbossts/resources | at java.io.FileOutputStream.open(Native Method) | at java.io.FileOutputStream.<init>(FileOutputStream.java:179) | at java.io.FileOutputStream.<init>(FileOutputStream.java:131) | at org.jboss.maven.plugins.thirdparty.util.JarUtil.extractJarFile(JarUtil.java:107) | at org.jboss.maven.plugins.thirdparty.BuildThirdpartyMojo.copyDependenciesAndGenrateCompInfo(BuildThirdpartyMojo.java:292) | at org.jboss.maven.plugins.thirdparty.BuildThirdpartyMojo.execute(BuildThirdpartyMojo.java:174) | at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:924) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:767) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:529) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) | at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) | at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) | at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) | at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) | at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) | at org.codehaus.classworlds.Launcher.main(Launcher.java:375) | | [513][valkyrie: thirdparty]$ ls thirdparty/jboss/jbossts/resources | jbossjta-properties.xml | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169327#4169327 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169327

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting unmarshalling vs. class loaders

by david.lloyd＠jboss.com

"scott.stark(a)jboss.org" wrote : No, I mean if the response object container the unmarshalled object that is going to be streamed by the transport layer after the handler has cleared the TCL, possibly in another thread. Ah, got it. In R3, the stream is associated with the request (and thereby the service), so on the server side, the proper TCL can easily be selected. Also, the server side contains a mechanism for dispatching asynchronous tasks (for the purpose of asynchronous cancellation originally) which can easily be leveraged for this purpose as well. The end result would be that any thread that does anything related to a request can be preconfigured ahead of time however we need. On the client side it's a little different but I think that we could set it up to select the right classloader for the duration of any unmarshalling or stream handling operation regardless of thread through the way stream handler API is invoked. I'll double-check that to be sure though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169319#4169319 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169319

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: check out sources fails

by kukeltje

But there are still more places which are *not* correct. http://www.jboss.org/jbossjbpm/gpd_sources/ http://www.jboss.org/jbossjbpm/bpel_sources/ http://www.jboss.org/jbossjbpm/pvm_sources/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169317#4169317 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169317

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: MDB.getActivationConfigProperties handling of no destina

by scott.stark＠jboss.org

ACK View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169312#4169312 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169312

17 years, 8 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 August 2008