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

[JBoss Microcontainer Development POJO Server] New message: "Re: Classloader VFS3 Integration"

by Ales Justin

JBoss development, A new message was posted in the thread "Classloader VFS3 Integration": http://community.jboss.org/message/521706#521706 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > I guess I don't see any reason it has to be just jboss-cl. The problem is there are a lot of VFS dependent projects and it is becoming a difficult to manage all the branches, so I was trying to see if there was a way we could chip away at getting them on the trunk as the projects we more and more stable with the VFS3 integration and an based on dependency order, jboss-cl was the next likely candidate. I think we should just set a reasonable date when we're gonna change them all at once. We give devs time till then - properly warn/promote this date. Then branch previous stuff to right branch versions, and move VFS3 stuff to respected trunks. Wrt jboss-cl, I know Adrian is currently working on some OSGi support, so might not be the best time to "sweep the rug under his feet". :-) > Below is a list of all the dependent projects that are used by AS. There may even be a few more that I haven't come across. Feel free to add any additional you can think of. > > http://community.jboss.org/docs/DOC-14634 I don't see Seam-int there: * http://anonsvn.jboss.org/repos/jbossas/projects/jboss-seam-int/trunk/ Although we need to check how much of VFS usage should be there once you move to VFS3. It might be that we won't need it anymore -- due to more standard URL, paths, ... I'll think about it if there are some others we missed. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521706#521706

14 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: StructureModificationChecker and Synch with VFS3"

by Ales Justin

JBoss development, A new message was posted in the thread "StructureModificationChecker and Synch with VFS3": http://community.jboss.org/message/521700#521700 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > I did some further digging on the use of ModificationType and ModificationActions. Outside of tests I do not see any usage of custom modification types/actions for any deployers. Is this still in use? Can it be cleaned up? I wouldn't clean it up. It's a feature that's implemented and tested. The fact is that it's not widely used, if used at all. Or why exactly would you remove it? You can limit some of the types for start, and log warning for the non-supported. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521700#521700

14 years, 4 months

1
0
0 / 0

[JBoss ESB Development] New message: "Building remote ESB client with maven"

by Morten Hauch

JBoss development, A new message was posted in the thread "Building remote ESB client with maven": http://community.jboss.org/message/521645#521645 Author : Morten Hauch Profile : http://community.jboss.org/people/hauch Message: -------------------------------------------------------------- WARNING: This is moved from the user forum. Hi The fine article http://community.jboss.org/docs/DOC-14651 made me suggest the construction of a common client jar (similar to jbossall_client.jar in the app server). Daniel Bevenius suggested that I placed my request here, and this is hereby done. Daniel also referred to a section in "Programmers Guide" that lists the dependencies of a remote client. I think one big step towards this common jar could be to add maven dependency configurations on these jars. Eg stax-1.2.0.jar: <dependency> <groupId>stax</groupId> <artifactId>stax</artifactId> <version>1.2.0</version> </dependency> This would make it possible to create a pom with these dependencies and depend on this in the client app (if build by maven) or to download and bundle the jars in a common jar. The largest challenge in this is that the jboss jars are unavailable on repos (as pointed out in the article), but this could (temporary) be solved as in the article (pointing to a jboss installation). Furthermore some of the components lack version specification but this must be a minor issue. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521645#521645

14 years, 4 months

1
0
0 / 0

[JBoss AS Development Deployment Framework] New message: "Deprecating VFSDeployer"

by Carlo de Wolf

JBoss development, A new message was posted in the thread "Deprecating VFSDeployer": http://community.jboss.org/message/521641#521641 Author : Carlo de Wolf Profile : http://community.jboss.org/people/wolfc Message: -------------------------------------------------------------- In relation to the upgrade to VFS 3, why don't we deprecate VFSDeployer? Right now we stand a chance that we'll get multiple deployer versions because version 1 needs to integrate with VFS 2 and version 2 on top of VFS 3. But most (if not all) of those deployers actually don't have any need for real file access. For example:EjbAnnotationMetaDataDeployer [1] actually needs to use the results of the annotation scanner to work. DummiesSerializedMetaDataDeployer [2] only needs an InputStream on the underlying file. (Also note that parsing deployer is a counter-intuitive name, because it's actually an file or I/O deployer.) In essence we could create an IODeployer in which we plug a DeploymentUnitIOManager and then have two implementations: VFS2DeploymentUnitIOManager and VFS3DeploymentUnitIOManager. Where it not that most deployers operate on a higher level abstraction anyway (classes or annotations etc.). In short we need a blueprint which makes all deployers VFS independent. Thus instead of deprecating a lot of deployer components, we just refactor them properly and do not create an O(x) maintenance burden, but an O(2). :-) [1] http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/de... [2] http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/reloaded/trun... -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521641#521641

14 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"

by Kabir Khan

JBoss development, A new message was posted in the thread "Pluggable dependency resolver": http://community.jboss.org/message/521562#521562 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- I have got contextual injection and basic supply/demand working, so KernelAllTestSuite is down to 18 errors and 32 failures, most of which are related to scoping. The supply/demand implementation is pretty simple so far. When registered, if a context has demand dependency items, they get recorded. When a context has supplies and its state is incremented, we try to resolve the contexts with demand di's waiting for that state. I hope that will suffice, since I don't want to get involved with the matchers, I might be wrong but I don't think they lend themselves to Similarly, the contextual injection mechanism is also quite light, we only index the wanted class on registring, and on incrementing the state we check for the classes. I don't do anything about the qualifiers. One thing I think we're lacking is "wrong order" tests for contextual injection, at least with qualifiers, so I need to add some. The same might be the case for supply/demand, which I need to check. I've been using concurrent collections in my DependencyResolver and Matchers, which might not be necessary. I thing al the access to the DependencyResolver + Matchers happens with the controller lock taken, but again I need to check that. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521562#521562

14 years, 4 months

1
0
0 / 0

[jBPM Development] New message: "Refresh button doesn't work in jbpm4 console application"

by sunil tiwari

JBoss development, A new message was posted in the thread "Refresh button doesn't work in jbpm4 console application": http://community.jboss.org/message/521509#521509 Author : sunil tiwari Profile : http://community.jboss.org/people/sunilkt Message: -------------------------------------------------------------- I am running jbpm4.2 console application on was6.1 with derby database . it's running fine and i am able to create process instanses and can see them in the process definations tab . My concern is , if i delete any process from the list shown it didn't get refreshed to show only remained process instances , even after clicking refresh button nothing happens . here if i logout and login again now i can see original list (No deleted row) . Even i found if clicked on process definations once it loads data from data base and cache it into the browser , in the same session if clicked the same link again and again it never goes to data base .Ideally clicking on refresh button does the same thing to hit the data base and get the updated data .. Any idea why the refresh didn't work . -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521509#521509

14 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: BeanMetaDataBuilder ignoring ignoreDestroy()?"

by David Lloyd

JBoss development, A new message was posted in the thread "BeanMetaDataBuilder ignoring ignoreDestroy()?": http://community.jboss.org/message/521460#521460 Author : David Lloyd Profile : http://community.jboss.org/people/david.lloyd@jboss.com Message: -------------------------------------------------------------- OK, I'll keep investigating this. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521460#521460

14 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Native library mapping at jboss-cl level"

by Adrian Brock

JBoss development, A new message was posted in the thread "Native library mapping at jboss-cl level": http://community.jboss.org/message/521436#521436 Author : Adrian Brock Profile : http://community.jboss.org/people/adrian@jboss.org Message: -------------------------------------------------------------- > mailto:thomas.diesler@jboss.com wrote: > > jboss-cl http://fisheye.jboss.org/changelog/JBossAS/projects/jboss-cl?cs=99732 > > I added http://fisheye.jboss.org/browse/JBossAS/projects/jboss-cl/trunk/classload... http://fisheye.jboss.org/browse/JBossAS/projects/jboss-cl/trunk/classload...: wich gets initialized by http://fisheye.jboss.org/browse/JBossAS/projects/jboss-osgi/projects/runt...:. > At resolve time, the http://fisheye.jboss.org/browse/JBossAS/projects/jboss-osgi/projects/runt...: adds NativeLibraryProvider instances to the http://fisheye.jboss.org/browse/JBossAS/projects/jboss-cl/trunk/classload...: > which are accessed by the http://fisheye.jboss.org/browse/JBossAS/projects/jboss-cl/trunk/classload...: like this > I tidied up your commit a bit. 1) The NativeLibraryProvider should be a top level interface since it is a public spi. 2) I made the map in the ClassLoaderPolicy thread safe, i.e. I made it volatile and used locals to get a consistent view. The way you had it, one thread could continue to see it as null for some time after another thread sets it. 3) I made the getNativeLibraries() method return an UnmodiableSet so that callers can't modify the map in unpredicatble ways. Some things that still need looking at: 1) Why are the getters public and what are they for? I'm a bit worried that somebody could use this api to find out the location of the native code and overwrite the file with their own dodgy code. :-) 2) I don't see any use of NativeLibraryProvider, but I am guessing you are not doing it correctly? They should be constructed against the ClassLoading Module and it (they) should be what initialises the ClassLoaderPolicy. 3) What's the point of the metadata in the base code if there is nothing that actually uses it? I expected to see something like a NativeLibraryProviderFactory on the ClassLoading object, which the Module then uses to turn the MetaData into Provider(s). You could create a default one that just copies the library into ${java.io.tmpdir}, although if that is a shared temporary directory, its not a good place to put code. ;-) 4) The xml parsing (including the xsds) and managed object annotations need adding and testing. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521436#521436

14 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"

by Kabir Khan

JBoss development, A new message was posted in the thread "Pluggable dependency resolver": http://community.jboss.org/message/521416#521416 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- Looking at supporting contextual injection in the indexing dependency resolver, I've stumbled upon an issue. The basic idea is simple, record which contexts depend on a given Class. When installing a context, check which contexts depend on it (and its superclasses + interfaces) and increment those. The problem is how to know the class of the context being installed? * KernelControllerContext.getBeanInfo() - do we want to require it to be a KCC? * ControllerContext.getTarget() - will not be valid until INSTANTIATED, but then again it probably does not make sense to have contextual injection with a lesser state, although I am not sure this is checked anywhere. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521416#521416

14 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Native library mapping at jboss-cl level"

by Adrian Brock

JBoss development, A new message was posted in the thread "Native library mapping at jboss-cl level": http://community.jboss.org/message/521413#521413 Author : Adrian Brock Profile : http://community.jboss.org/people/adrian@jboss.org Message: -------------------------------------------------------------- On a related note. It might be a good idea to add a "security option" for this feature.. e.g. something like only signed jars can deploy native code this way. i.e. have a new security permission for this feature (with the option on the deployer to enable/disable the check). Native code can bypass the java sandbox, so I can imagine some people would want to be able to lock this down if they don't trust their developers. ;-) -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521413#521413

14 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2010