[JBoss-dev] Anyone looked at dependency-manager task?
Just curious if anyone has had time to look at the dependency-manager task usage in the buildmagic-2.0 tree? If not could I get a few peeps to have a look and give me some feedback on how well it works to download depends to build this project? cvs get -r buildmagic-2_0 buildmagic cd buildmagic ./build/build.sh Sanka, --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-693239 ] JBoss ClassLoader implementation is unappropriate for EJB co
Bugs item #693239, was opened at 2003-02-25 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=693239group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Thomas Pasch (aanno) Assigned to: Nobody/Anonymous (nobody) Summary: JBoss ClassLoader implementation is unappropriate for EJB co Initial Comment: The Problem -- EJB (jar), WEB (war), and enterprise (ear) archives should be isolated from another. This especially means that: (a) independant packed components could use different version of a file with the same qualified name (b) independant packed components could call each other (i.e. home, remote, and local interfaces) JBoss ClassLoader design will cache all Class instances globally in standard configuration. This violates (a). It is possible to switch to (ear) archive-wise caching. But this violates (b), because the (client interfaces) packed with component 1 will be loaded with a different ClassLoader than the interface definition packed in component 2 (that also implements the bean) if both components are deployed on the same JVM. Violation of (b) normally shows up in a ClassCastException in PortableRemoteObject.narrow(). In summary it is impossible in JBoss to adhere to (a) and (b) at the same time. Proposed solution -- There are two ways around this problem: - disable the local call optimisation for call between independant packed components or - use a IIOP like scheme for all calls. IIOP will only transfer data members of object instances. It will NOT share Class implementation between independant packed component. Kind regards, aanno -- Comment By: Thomas Pasch (aanno) Date: 2003-03-10 12:05 Message: Logged In: YES user_id=349837 I put this point to a broader discussion at http://www.jboss.org/forums/thread.jsp?forum=92thread=289 64 . I also proposed an other solution to this problem there. I'm currently not sure if I would have posted this better as RFE (but I'm still inclined to regard this as bug). Some developers are also working on the very same problem. See their thread at http://sourceforge.net/mailarchive/message.php?msg_id=3852 655 . This work is sometimes referred as Hierachical ClassLoader. I really think that their proposal is not an appropriate solution, though... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=693239group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Eclipse with HEAD and 3.2 opened at same time?
Just use Check Out As... to check out HEAD and name it something like JBoss HEAD. Next, just use Check Out As... again and check out the 3.2 branch into something like JBoss 3.2. That way both branches can be in the same workspace at the same time. -Phil Jason Dillon [EMAIL PROTECTED] Sent by: To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: ceforge.netSubject: Re: [JBoss-dev] Eclipse with HEAD and 3.2 opened at same time? 03/09/2003 02:57 AM Please respond to jboss-development Starting two instances is a pain in the ass on OS X :-( --jason On Sunday, March 9, 2003, at 08:51 AM, Igor Fedorenko wrote: What do you want to do? Won't two Eclipse instances do? -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] Sent: Saturday, March 08, 2003 5:02 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Eclipse with HEAD and 3.2 opened at same time? Does anyone one if it is possible to get eclipse two have JBoss HEAD and JBoss 3.2 opened at the same time? --jason --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] dynamic proxy constructor creation caching
I wonder why dynamic proxy const is not cached, for instance in
BaseLocalProxyFctory.
switching :
InvocationHandler ih = new InvocationHandlerImpl();
Proxy.newProxyInstance(classloader, new Class[]{itf.class}, ih);
to the code :
InvocationHandler ih = new InvocationHandlerImpl();
cstr.newInstance(new Object[]{ih});
with the following code executed before :
Class clazz = Proxy.getProxyClass(Thread.currentThread().getContextClassLoader(), new
Class[]{itf.class});
Constructor cstr = clazz.getConstructor(new Class[]{InvocationHandler.class});
is very much faster, with jdk1.4.1_01 and a loop of 100
I got 21.11 seconds versus 0.38 seconds.
In fact, getProxyClass() is very slow.
I know were going to use new AOP framework and that might be different, but current
3.xx production
release still use DP.
julien
___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Possibility to override LoaderResository
Hi,
I saw you changes in cvs regarding mx.loading. Great that you are
relaxing the signature restriction! But I also saw that you have added
the possibility to let the heirirachical load from parent first; this
would be a welcome addition and might perhaps make it a little bit
easier to live with the current classloader architecture (one might at
least place interface/param classes in the global repository). However;
i do not understand how it will work.
As far as I can see this would be done through heir.loadClass(), but as
far as I can see it this method is never ever called (except from
UnifiedClassLoader.loadClass, but wich is overridden in
UnifiedClassLoader3.
Is not the loading scheme actually this:
ucl3.loadClass-LoadMgr-beginLoadTask(and then either - i order).
1. ucl3.repository-loadClassFromCache
2.
ucl3.repository-loadClassFromClassLoader-ucl3-loadClassLocally-ucl.super.loadClass()
3.
ucl3.repository-getPackageClassLoaders-ClassLoadingTask-run-ucl3-loadClassLocally.
As far as I can see it there is nowhere in this scheme that java2 parent
delegation actually can play any role apart from the cache (the class
must already have been loaded in a parent) and in getPackageClassLoader.
The following scenario for example would not allow for Java2 parent
delegation.
Global rep: MyInterface.class
HeirRep: MyInterface.class MyImpl.class
Because if MyImpl.class was loaded the first and MyInterface.class was
not previously loaded we would end up in stage 2 and the classloader
would load MyInterface.class from HeirRep. The only way in the current
scheme would be to do something with loadClassFromClassLoader.
Another thing I have been noting during my (frustrating) work with this
how the caching work in an hierarchical situation: when classes are
loaded through getPackageClassLoader classes will be cached not in the
repository the class had its classloader, but in the repository where
the classloader how started the loading is located. This means that a
class can actually be loaded through a repository hier up the chain
without being cached there.
Should not this part in LoadMgr:
if( loadTask.threadTaskCount == 0 )
{
Class loadedClass = threadTask.getLoadedClass();
if( loadedClass != null )
{
ClassLoader loader = loadedClass.getClassLoader();
// Place the loaded class into the repositry cache
repository.cacheLoadedClass(threadTask.getClassname(),
loadedClass, loader);
}
synchronized( loadTask )
{
loadTask.state = ClassLoadingTask.FINISHED;
loadTask.notify();
}
}
Instead use the UCL3.repository to cache the class?
Well, some comments just. And by the way: thanks for all your hard work.
//Peter
mån 2003-03-03 klockan 20.01 skrev Scott M Stark:
Yes, the redeploy semantic through the proxy was too much. I will handle the
changes to allow for subclassing LoaderRespoitory this week.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Peter Antman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 03, 2003 6:53 AM
Subject: [JBoss-dev] Possibility to override LoaderResository
Hi,
my last sugestion on how to enhance the scoped loader repository stuff
does not seems to have been welcomed into JBoss. However it would be
verry nice if it was possible to extends LoaderRespoitory and
EARDeployer outside of the jboss package hierarkies. This is not
possible now due to some protected signatures in jboss.mx.loading and
the way the EARDeployer is written. Some fairly small changes would
however make it possible to define your own repository strategies. Here
are the diffs to do it. Is these changes possible to get into the 3.0
line or would they distrupt any current funktionality that I do not
understand (security wise for example):
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
CTO WWW: http://www.tim.se
Email: [EMAIL PROTECTED]WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-700211 ] jboss-web.sar fails deploying in vanilla download
Bugs item #700211, was opened at 2003-03-08 20:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=700211group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Ryan Hoegg (rhoegg) Assigned to: Nobody/Anonymous (nobody) Summary: jboss-web.sar fails deploying in vanilla download Initial Comment: I downloaded jboss-3.0.6.zip and installed it on Windows in C:\Program Files. When trying to start with run.bat, all wars fail to deploy. They report a FileNotFoundException for default-web.xml. This file exists, but Jetty has trouble finding it because somehow it has translated Program Files to Program%20Files. JBoss 3.0.6 with tomcat works fine. I moved JBoss to C:\Java and it worked fine (as there are no spaces in the path) -- Comment By: Jeff Davies (jdavies) Date: 2003-03-10 10:55 Message: Logged In: YES user_id=88633 You discovered the problem. According to the JBoss Quick Start Guide (last paragraph, pg 14) you must not install JBoss into a directory that contains space characters. I recommend that this bug be closed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=700211group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] DefaultPartition in ClusteredHttpSessionEB.jar
Another question, org.jboss.management.j2ee.cluster.HAManagementService has DefaultPartition hardcoded and there seem to be no way to configure it. Should I fix this too? -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED] Sent: Saturday, March 08, 2003 9:37 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] DefaultPartition in ClusteredHttpSessionEB.jar Yes, expand it. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Igor Fedorenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sourceforge. Net (E-mail) [EMAIL PROTECTED] Sent: Friday, March 07, 2003 2:44 PM Subject: [JBoss-dev] DefaultPartition in ClusteredHttpSessionEB.jar Hi, Is the any reason why DefaultPartition name is packaged into ClusteredHttpSessionEB.jar file which in turn is packaged into jbossha-httpsession.sar file (this is for 3.2)? This makes changing partition names a little bit more complicated. Can I change build.xml to leave this stuff expanded? Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Possibility to override LoaderResository
I have not tested the java2ParentDelegaton addition, but yes this can only come
in at the loader repository level which is either the cache or the ordering
of the class loaders as determined by getPackageClassLoaders. If java2ParentDelegaton
is false, then the child loader repository's should not look to its parent loader
repository cache until it as checked its cache as well is its local class loaders. This
allows MyInterface.class to be loaded from the child regardless of its existence
in the parent loader repository. I'll be completing a few class loader changes today
and tomorrow and then doing an 3.2.0RC4 release so see if these accomodate
legacy deployment packagings any better.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Peter Antman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 10, 2003 11:26 AM
Subject: Re: [JBoss-dev] Possibility to override LoaderResository
Hi,
I saw you changes in cvs regarding mx.loading. Great that you are
relaxing the signature restriction! But I also saw that you have added
the possibility to let the heirirachical load from parent first; this
would be a welcome addition and might perhaps make it a little bit
easier to live with the current classloader architecture (one might at
least place interface/param classes in the global repository). However;
i do not understand how it will work.
As far as I can see this would be done through heir.loadClass(), but as
far as I can see it this method is never ever called (except from
UnifiedClassLoader.loadClass, but wich is overridden in
UnifiedClassLoader3.
Is not the loading scheme actually this:
ucl3.loadClass-LoadMgr-beginLoadTask(and then either - i order).
1. ucl3.repository-loadClassFromCache
2.
ucl3.repository-loadClassFromClassLoader-ucl3-loadClassLocally-ucl.super.loadClass()
3.
ucl3.repository-getPackageClassLoaders-ClassLoadingTask-run-ucl3-loadClassLocally.
As far as I can see it there is nowhere in this scheme that java2 parent
delegation actually can play any role apart from the cache (the class
must already have been loaded in a parent) and in getPackageClassLoader.
The following scenario for example would not allow for Java2 parent
delegation.
Global rep: MyInterface.class
HeirRep: MyInterface.class MyImpl.class
Because if MyImpl.class was loaded the first and MyInterface.class was
not previously loaded we would end up in stage 2 and the classloader
would load MyInterface.class from HeirRep. The only way in the current
scheme would be to do something with loadClassFromClassLoader.
Another thing I have been noting during my (frustrating) work with this
how the caching work in an hierarchical situation: when classes are
loaded through getPackageClassLoader classes will be cached not in the
repository the class had its classloader, but in the repository where
the classloader how started the loading is located. This means that a
class can actually be loaded through a repository hier up the chain
without being cached there.
Should not this part in LoadMgr:
if( loadTask.threadTaskCount == 0 )
{
Class loadedClass = threadTask.getLoadedClass();
if( loadedClass != null )
{
ClassLoader loader = loadedClass.getClassLoader();
// Place the loaded class into the repositry cache
repository.cacheLoadedClass(threadTask.getClassname(),
loadedClass, loader);
}
synchronized( loadTask )
{
loadTask.state = ClassLoadingTask.FINISHED;
loadTask.notify();
}
}
Instead use the UCL3.repository to cache the class?
Well, some comments just. And by the way: thanks for all your hard work.
//Peter
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-701106 ] Patch request for StatefulSessionInstanceCache class
Bugs item #701106, was opened at 2003-03-10 20:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=701106group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Rod Burgett (rodburgett) Assigned to: Nobody/Anonymous (nobody) Summary: Patch request for StatefulSessionInstanceCache class Initial Comment: I'd like to extend the StatefulSessionInstanceCache class (from server/src/main/org/jboss/ejb/plugins) and synchronize bean removal with other processing. A simple extension to allow this is to update the removePassivated() method to surround the actual removal with calls to protected pre- and post-removal methods. The attached diff file includes this update as well as the addition of empty implementations of the new pre- and post-removal methods. This patch request is associated with v3.2, but the same change may be applied to v3.0. I have a second, nearly identical, diff file for v3.0. The change is exactly the same, only the line numbers change. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=701106group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Possibility to override LoaderResository
mån 2003-03-10 klockan 21.15 skrev Scott M Stark:
I have not tested the java2ParentDelegaton addition, but yes this can only come
in at the loader repository level which is either the cache or the ordering
of the class loaders as determined by getPackageClassLoaders. If java2ParentDelegaton
is false, then the child loader repository's should not look to its parent loader
repository cache until it as checked its cache as well is its local class loaders.
This
allows MyInterface.class to be loaded from the child regardless of its existence
in the parent loader repository. I'll be completing a few class loader changes today
and tomorrow and then doing an 3.2.0RC4 release so see if these accomodate
legacy deployment packagings any better.
Great, I look forward to see what you will do. My experience from the
current way is however that the load local first is really the way if
works (except if a class is available in cache higher up the chain)
since a component is now in one classloader and that that classloader
will have its way before getPackageClassLoaders. The hard thing to get
working is to have it load classes that exists above it before it
tries the local ones (this would make it possible to place interface
classes globale when working i JBoss without having to exterminate them
from all local ejb-jars and whats more.
//Peter
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Peter Antman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 10, 2003 11:26 AM
Subject: Re: [JBoss-dev] Possibility to override LoaderResository
Hi,
I saw you changes in cvs regarding mx.loading. Great that you are
relaxing the signature restriction! But I also saw that you have added
the possibility to let the heirirachical load from parent first; this
would be a welcome addition and might perhaps make it a little bit
easier to live with the current classloader architecture (one might at
least place interface/param classes in the global repository). However;
i do not understand how it will work.
As far as I can see this would be done through heir.loadClass(), but as
far as I can see it this method is never ever called (except from
UnifiedClassLoader.loadClass, but wich is overridden in
UnifiedClassLoader3.
Is not the loading scheme actually this:
ucl3.loadClass-LoadMgr-beginLoadTask(and then either - i order).
1. ucl3.repository-loadClassFromCache
2.
ucl3.repository-loadClassFromClassLoader-ucl3-loadClassLocally-ucl.super.loadClass()
3.
ucl3.repository-getPackageClassLoaders-ClassLoadingTask-run-ucl3-loadClassLocally.
As far as I can see it there is nowhere in this scheme that java2 parent
delegation actually can play any role apart from the cache (the class
must already have been loaded in a parent) and in getPackageClassLoader.
The following scenario for example would not allow for Java2 parent
delegation.
Global rep: MyInterface.class
HeirRep: MyInterface.class MyImpl.class
Because if MyImpl.class was loaded the first and MyInterface.class was
not previously loaded we would end up in stage 2 and the classloader
would load MyInterface.class from HeirRep. The only way in the current
scheme would be to do something with loadClassFromClassLoader.
Another thing I have been noting during my (frustrating) work with this
how the caching work in an hierarchical situation: when classes are
loaded through getPackageClassLoader classes will be cached not in the
repository the class had its classloader, but in the repository where
the classloader how started the loading is located. This means that a
class can actually be loaded through a repository hier up the chain
without being cached there.
Should not this part in LoadMgr:
if( loadTask.threadTaskCount == 0 )
{
Class loadedClass = threadTask.getLoadedClass();
if( loadedClass != null )
{
ClassLoader loader = loadedClass.getClassLoader();
// Place the loaded class into the repositry cache
repository.cacheLoadedClass(threadTask.getClassname(),
loadedClass, loader);
}
synchronized( loadTask )
{
loadTask.state = ClassLoadingTask.FINISHED;
loadTask.notify();
}
}
Instead use the UCL3.repository to cache the class?
Well, some comments just. And by the way: thanks for all your hard work.
//Peter
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 10-March-2003
JBoss daily test results SUMMARY Number of tests run: 1120 Successful tests: 1106 Errors:14 Failures: 0 [time of test: 2003-03-10.20-42 GMT] [java.version: 1.4.1_01] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_01-b01] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2003-03-10.20-42 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: CtsCmp2UnitTestCase Test:testV1(org.jboss.test.cts.test.CtsCmp2UnitTestCase) Type:error Exception: javax.naming.NameNotFoundException Message: v1 not bound - Suite: CtsCmp2UnitTestCase Test:testV2(org.jboss.test.cts.test.CtsCmp2UnitTestCase) Type:error Exception: javax.naming.NameNotFoundException Message: v2 not bound - Suite: CtsCmp2UnitTestCase Test:testV1Sar(org.jboss.test.cts.test.CtsCmp2UnitTestCase) Type:error Exception: javax.naming.NameNotFoundException Message: v1 not bound - Suite: CtsCmp2UnitTestCase Test:testV2Sar(org.jboss.test.cts.test.CtsCmp2UnitTestCase) Type:error Exception: javax.naming.NameNotFoundException Message: v2 not bound - Suite: StatefulSessionUnitTestCase Test: testInVMSessionHandlePassivation(org.jboss.test.cts.test.StatefulSessionUnitTestCase) Type:error Exception: java.rmi.NoSuchObjectException Message: Could not activate; failed to restore state; CausedByException is: C:\cvs\JBoss3.2\jboss-3.2\build\output\jboss-3.2.0RC4\server\all\data\sessions\StatefulSessionBean-dd4wrskt-4\dd4wrvk0-b.ser (The system cannot find the file specified) - Suite: PathologicalUnitTestCase Test:testErrorFromRemove(org.jboss.test.entity.test.PathologicalUnitTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: InvocationLayerStressTestCase Test: testOILMutliSessionOneConnection(org.jboss.test.jbossmq.perf.InvocationLayerStressTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: SecurityUnitTestCase Test:runValidDynDurSub(org.jboss.test.jbossmq.test.SecurityUnitTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: DeployXMBeanUnitTestCase Test:testDeployUserXMBean(org.jboss.test.jmx.test.DeployXMBeanUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/user-xmbean.sar; - nested throwable: (org.jboss.deployment.DeploymentException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute persistPolicy with value Never must have a value from the list NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER .; - nested throwable: (javax.management.NotCompliantMBeanException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute persistPolicy with value Never must have a value from the list NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER .)) - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/missingclass-service.xml; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: EnterpriseEntityStressTestCase Test: testB2B(org.jboss.test.lock.test.EnterpriseEntityStressTestCase$Entity_Option_C_Test) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: JSR77SpecUnitTestCase Test:testNavigation(org.jboss.test.management.test.JSR77SpecUnitTestCase) Type:error Exception: javax.management.InstanceNotFoundException Message:
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 10-March-2003
JBoss daily test results SUMMARY Number of tests run: 1067 Successful tests: 1061 Errors:2 Failures: 4 [time of test: 2003-03-10.13-20 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.4] See http://users.jboss.org/~starksm/Branch_3_0/2003-03-10.13-20 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SimpleUnitTestCase Test:testHaParitionName(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.CommunicationException Message: Failed to retrieve stub from server 172.17.66.53:1100 - Suite: SecurityUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SecurityUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: SecurityUnitTestCase Test: testSecureHttpInvokerFailure(org.jboss.test.naming.test.SecurityUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - Suite: RemoteServiceUnitTestCase Test:testRecContent(org.jboss.test.jmx.test.RemoteServiceUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: No managed MBean registry avaliable. Start JBoss with -Djbossmx.mbean.registry.class=org.jboss.mx.server.registry.ManagedMBeanRegistry - --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DefaultPartition in ClusteredHttpSessionEB.jar
Leave this to me as I need to update this class for the changes made to the jsr77 layer. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Igor Fedorenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 10, 2003 11:24 AM Subject: RE: [JBoss-dev] DefaultPartition in ClusteredHttpSessionEB.jar Another question, org.jboss.management.j2ee.cluster.HAManagementService has DefaultPartition hardcoded and there seem to be no way to configure it. Should I fix this too? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-701282 ] BeanShell JBoss sub-deployer added
Change Notes item #701282, was opened at 2003-03-10 18:03
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=381174aid=701282group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Priority: 5
Submitted By: Scott M Stark (starksm)
Assigned to: Nobody/Anonymous (nobody)
Summary: BeanShell JBoss sub-deployer added
Initial Comment:
A BeanShell (BSH, www.beanshell.org) sub-deployer in
has been added to 3.2+. It is in module varia and you
can find its lib in varia/output/lib/bsh-deployer.sar.
It allows you to hot-deploy *.bsh files in /deploy.
SIMPLE USAGE: client-only
=
In its simple usage, the script will act as a simple
client-script making
invocations on other objects. Each script can follow the
org.jboss.system.Service interface i.e. the create,
start, stop and destroy
calls. You can implement only a subset of those. Thus,
a very simply
one-line script can be: Simple.bsh:
void start() { System.out.println (I'm called!); }
that's it.
ADVANCED USAGE: server script!
==
But it is almost as easy to make your script a JBoss
service fully
invocable/administrable through JMX! For this, your
script can implement any
of the methods of the following interface:
public interface ScriptService
extends org.jboss.system.Service
{
public String objectName ();
public String[] dependsOn ();
public Class[] getInterfaces ();
public void setCtx (ServiceMBeanSupport wrapper);
}
You can implement the objectName method to choose your
own MBean ObjectName.
You can implement the dependsOn method to return a set
of JMX MBean
ObjectName (as string) on which you depends (for
service lifecyle).
You can implement the getInterfaces method to return
the set of interfaces
that you *say* your script do implement. Your wrapper
will analyse these
interfaces and fully generate the associated JMX
MBeanInfo (the script
wrapper is a Dynamic MBean).
Example, let's say you have this interface:
public interface MyIntf
{
public void doThat();
public String getRWString ();
public void setRWString (String val);
public String getROString ();
}
You could then provide this script:
String name = bla;
String objectName () { return
jboss.scripts:service=myService; }
Class[] getInterfaces () { return new Class[]
{MyIntf.class}; }
void create () { System.out.println (Create called
on me); }
void doThat () { System.out.println (doThat called); }
String getRWString() { return super.name; }
void setRWString(String bla) { super.name = bla; }
String getROString() { return I am read-only!; }
Then, not only can you invoke methods and get/set
attributes on your script
using JMX, you can also browse your scripts using the
http://localhost:8080/jmx-console/ and see all
available methods/attributes
(MBeanInfo is generated by the DynamicMBean script wrapper)
Infos on BeanShell are available here: www.beanshell.org
Cheers,
Sacha
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=381174aid=701282group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Move MarshalledValue* to common module?
I would like to move the org.jboss.invocation.MarshalledValue* to the commons package, so it can be used by non-ejb dependent code. Does any have an issue with this? Does this create a problem for client jars? -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Move MarshalledValue* to common module?
I have another issue now... should have checked before sending this email. I have a written new basic service ObjectCopier, which is an MBean that knows how to *efficiently* deep copy objects. This means that I track metadata so we can avoid serialize/ deserialize. Anyway, I wanted add this to the common module, because it is a generic service that will be used by several modules (CMP and Cache for now). The problem is common does not build after system, so I can't use ServiceMBeanSupport. Should we add a new module for common services or move the ServiceMBeanSupport stuff to common or something else or should I put my code server? -dain On Monday, March 10, 2003, at 08:15 PM, Dain Sundstrom wrote: I would like to move the org.jboss.invocation.MarshalledValue* to the commons package, so it can be used by non-ejb dependent code. Does any have an issue with this? Does this create a problem for client jars? -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Make $7500 A Month Or It's FREE!!!.......... wsb
Online gambling is taking off! In 2002 alone, the Online Casino industry earned over $3 billion, and is expected to skyrocket to over $5 billion annually by the end of 2003. We've partnered with three of the top online casinos, and we'll give you your very own Online Gaming Portal where your visitors will be able to play over 20 of the most popular games with real money. The best part is, you'll keep 40-50% of the net game play from all three of these casinos, while they do all of the work for you! We're so confident in your success that we'll guarantee you'll hit your $7,500/month goal within your first 6 months or it's FREE!!! For more information, please visit our web site: www.yourcasinobiz.com I no longer care to receive such information [EMAIL PROTECTED]. jnekemgaqwepknwrnvdo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Move MarshalledValue* to common module?
I would like to move the org.jboss.invocation.MarshalledValue* to the commons package, so it can be used by non-ejb dependent code. good point marcf Does any have an issue with this? Does this create a problem for client jars? -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Move MarshalledValue* to common module?
I don't think there should be any services in common, only utility type classes. The server module seems like the approriate place for core utility services that are not needed by the bootstrap server footprint. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 10, 2003 6:32 PM Subject: Re: [JBoss-dev] Move MarshalledValue* to common module? I have another issue now... should have checked before sending this email. I have a written new basic service ObjectCopier, which is an MBean that knows how to *efficiently* deep copy objects. This means that I track metadata so we can avoid serialize/ deserialize. Anyway, I wanted add this to the common module, because it is a generic service that will be used by several modules (CMP and Cache for now). The problem is common does not build after system, so I can't use ServiceMBeanSupport. Should we add a new module for common services or move the ServiceMBeanSupport stuff to common or something else or should I put my code server? -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 10-March-2003
JBoss daily test results SUMMARY Number of tests run: 1120 Successful tests: 1110 Errors:10 Failures: 0 [time of test: 2003-03-11.01-42 GMT] [java.version: 1.4.1_01] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_01-b01] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2003-03-11.01-42 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: StatefulSessionUnitTestCase Test: testInVMSessionHandlePassivation(org.jboss.test.cts.test.StatefulSessionUnitTestCase) Type:error Exception: java.rmi.NoSuchObjectException Message: Could not activate; failed to restore state; CausedByException is: C:\cvs\JBoss3.2\jboss-3.2\build\output\jboss-3.2.0RC4\server\all\data\sessions\StatefulSessionBean-dd57h2cg-4\dd57h5dt-b.ser (The system cannot find the file specified) - Suite: PathologicalUnitTestCase Test:testErrorFromRemove(org.jboss.test.entity.test.PathologicalUnitTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: InvocationLayerStressTestCase Test: testOILMutliSessionOneConnection(org.jboss.test.jbossmq.perf.InvocationLayerStressTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: SecurityUnitTestCase Test:runValidDynDurSub(org.jboss.test.jbossmq.test.SecurityUnitTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: DeployXMBeanUnitTestCase Test:testDeployUserXMBean(org.jboss.test.jmx.test.DeployXMBeanUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/user-xmbean.sar; - nested throwable: (org.jboss.deployment.DeploymentException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute persistPolicy with value Never must have a value from the list NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER .; - nested throwable: (javax.management.NotCompliantMBeanException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute persistPolicy with value Never must have a value from the list NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER .)) - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/missingclass-service.xml; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: EnterpriseEntityStressTestCase Test: testB2B(org.jboss.test.lock.test.EnterpriseEntityStressTestCase$Entity_Option_C_Test) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: JSR77SpecUnitTestCase Test:testNavigation(org.jboss.test.management.test.JSR77SpecUnitTestCase) Type:error Exception: javax.management.InstanceNotFoundException Message: jboss.management.local:J2EEApplication=cts-v1cmp.ear,J2EEServer=Local,j2eeType=EJBModule,name=cts-v1cmp.jar is not registered. - Suite: HttpsUnitTestCase Test:testJSSE(org.jboss.test.security.test.HttpsUnitTestCase) Type:error Exception: java.net.BindException Message: Address already in use: JVM_Bind - Suite: SRPUnitTestCase Test:testEchoArgs(org.jboss.test.security.test.SRPUnitTestCase) Type:error Exception: java.lang.reflect.UndeclaredThrowableException Message: - --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DTD hell
Not based on my testing. Any elements must still be declared. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Luke Taylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 08, 2003 10:50 AM Subject: Re: [JBoss-dev] DTD hell Scott M Stark wrote: ... !ELEMENT loader-repository-config (ANY) Does it make any difference if you leave the brackets off the ANY ? http://www.w3.org/TR/REC-xml#NT-elementdecl -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JDK 1.4.1 on OS X out and breaks build
I just upgraded to 1.4.1 on OS X and now the build won't work. I tried a fresh checkout, but that didn't help. Jason is this working on your mac. -dain bash-2.05a$ java -version java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-39) Java HotSpot(TM) Client VM (build 1.4.1_01-14, mixed mode) bash-2.05a$ ./build.sh build.sh: Executing: /Users/dain/work/jboss/x/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property _buildmagic:init:local-properties: [copy] Copying 1 file to /Users/dain/work/jboss/x/jboss-head/build configure-project: [echo] groups: default [echo] modules: common,naming,remoting,jmx,system,aop,cache,j2ee,management,transaction, persistence,server,blocks,console,security,messaging,connector,varia,clu ster,jetty,jboss.net,iiop _buildmagic:modules:most: == == == Executing 'most' in module 'common'... == == compile-mbean-sources: [mkdir] Created dir: /Users/dain/work/jboss/x/jboss-head/common/output/gen/classes [execmodules] Running mbeaninterface/ [execmodules] Generating output for 'org.jboss.util.property.jmx.SystemPropertyClassValue' using template file 'jar:file:/Users/dain/work/jboss/x/jboss-head/thirdparty/xdoclet- xdoclet/lib/xdoclet-jmx-module-jb4.jar!/xdoclet/modules/jmx/resources/ mbean.xdt'. [execmodules] (XDocletMain.start 51 ) Running XDoclet failed. [execmodules] (XDocletMain.start 52 ) Running XDoclet failed. [execmodules] xdoclet.template.TemplateException: Error in template file: corresponding /XDtClass:classOf not found, line=8 of template file: jar:file:/Users/dain/work/jboss/x/jboss-head/thirdparty/xdoclet- xdoclet/lib/xdoclet-jmx-module-jb4.jar!/xdoclet/modules/jmx/resources/ mbean.xdt [execmodules] at xdoclet.template.TemplateEngine.handleBlockTag(TemplateEngine.java:824) [execmodules] at xdoclet.template.TemplateEngine.handleTag(TemplateEngine.java:425) [execmodules] at xdoclet.template.TemplateEngine.generate(TemplateEngine.java:324) [execmodules] at xdoclet.template.TemplateEngine.start(TemplateEngine.java:373) [execmodules] at xdoclet.TemplateSubTask.startEngine(TemplateSubTask.java:559) [execmodules] at xdoclet.TemplateSubTask.generateForClass(TemplateSubTask.java:765) And so on... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JDK 1.4.1 on OS X out and breaks build
I am currently using 1.4.1 p10. I will download the latest ASAP. --jason On Tuesday, March 11, 2003, at 01:13 PM, Dain Sundstrom wrote: I just upgraded to 1.4.1 on OS X and now the build won't work. I tried a fresh checkout, but that didn't help. Jason is this working on your mac. -dain bash-2.05a$ java -version java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-39) Java HotSpot(TM) Client VM (build 1.4.1_01-14, mixed mode) bash-2.05a$ ./build.sh build.sh: Executing: /Users/dain/work/jboss/x/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property _buildmagic:init:local-properties: [copy] Copying 1 file to /Users/dain/work/jboss/x/jboss-head/build configure-project: [echo] groups: default [echo] modules: common,naming,remoting,jmx,system,aop,cache,j2ee,management,transaction ,persistence,server,blocks,console,security,messaging,connector,varia,c luster,jetty,jboss.net,iiop _buildmagic:modules:most: == == == Executing 'most' in module 'common'... == == compile-mbean-sources: [mkdir] Created dir: /Users/dain/work/jboss/x/jboss-head/common/output/gen/classes [execmodules] Running mbeaninterface/ [execmodules] Generating output for 'org.jboss.util.property.jmx.SystemPropertyClassValue' using template file 'jar:file:/Users/dain/work/jboss/x/jboss-head/thirdparty/xdoclet- xdoclet/lib/xdoclet-jmx-module-jb4.jar!/xdoclet/modules/jmx/resources/ mbean.xdt'. [execmodules] (XDocletMain.start 51 ) Running XDoclet failed. [execmodules] (XDocletMain.start 52 ) Running XDoclet failed. [execmodules] xdoclet.template.TemplateException: Error in template file: corresponding /XDtClass:classOf not found, line=8 of template file: jar:file:/Users/dain/work/jboss/x/jboss-head/thirdparty/xdoclet- xdoclet/lib/xdoclet-jmx-module-jb4.jar!/xdoclet/modules/jmx/resources/ mbean.xdt [execmodules] at xdoclet.template.TemplateEngine.handleBlockTag(TemplateEngine.java:824) [execmodules] at xdoclet.template.TemplateEngine.handleTag(TemplateEngine.java:425) [execmodules] at xdoclet.template.TemplateEngine.generate(TemplateEngine.java:324) [execmodules] at xdoclet.template.TemplateEngine.start(TemplateEngine.java:373) [execmodules] at xdoclet.TemplateSubTask.startEngine(TemplateSubTask.java:559) [execmodules] at xdoclet.TemplateSubTask.generateForClass(TemplateSubTask.java:765) And so on... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Move MarshalledValue* to common module?
Why not add it to system? --jason On Tuesday, March 11, 2003, at 09:32 AM, Dain Sundstrom wrote: I have another issue now... should have checked before sending this email. I have a written new basic service ObjectCopier, which is an MBean that knows how to *efficiently* deep copy objects. This means that I track metadata so we can avoid serialize/ deserialize. Anyway, I wanted add this to the common module, because it is a generic service that will be used by several modules (CMP and Cache for now). The problem is common does not build after system, so I can't use ServiceMBeanSupport. Should we add a new module for common services or move the ServiceMBeanSupport stuff to common or something else or should I put my code server? -dain On Monday, March 10, 2003, at 08:15 PM, Dain Sundstrom wrote: I would like to move the org.jboss.invocation.MarshalledValue* to the commons package, so it can be used by non-ejb dependent code. Does any have an issue with this? Does this create a problem for client jars? -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Move MarshalledValue* to common module?
I don't need to move it anymore, because I'm going to put my new code in server. I think this will need to be moved when we get more of the persistence engine moved, because we use MarshalledValue for BLOBs. -dain On Tuesday, March 11, 2003, at 12:57 AM, Jason Dillon wrote: Why not add it to system? --jason On Tuesday, March 11, 2003, at 09:32 AM, Dain Sundstrom wrote: I have another issue now... should have checked before sending this email. I have a written new basic service ObjectCopier, which is an MBean that knows how to *efficiently* deep copy objects. This means that I track metadata so we can avoid serialize/ deserialize. Anyway, I wanted add this to the common module, because it is a generic service that will be used by several modules (CMP and Cache for now). The problem is common does not build after system, so I can't use ServiceMBeanSupport. Should we add a new module for common services or move the ServiceMBeanSupport stuff to common or something else or should I put my code server? -dain On Monday, March 10, 2003, at 08:15 PM, Dain Sundstrom wrote: I would like to move the org.jboss.invocation.MarshalledValue* to the commons package, so it can be used by non-ejb dependent code. Does any have an issue with this? Does this create a problem for client jars? -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Move MarshalledValue* to common module?
What is up with the unified interception framework? I assume this will be part of it yes? --jason On Tuesday, March 11, 2003, at 02:14 PM, Dain Sundstrom wrote: I don't need to move it anymore, because I'm going to put my new code in server. I think this will need to be moved when we get more of the persistence engine moved, because we use MarshalledValue for BLOBs. -dain On Tuesday, March 11, 2003, at 12:57 AM, Jason Dillon wrote: Why not add it to system? --jason On Tuesday, March 11, 2003, at 09:32 AM, Dain Sundstrom wrote: I have another issue now... should have checked before sending this email. I have a written new basic service ObjectCopier, which is an MBean that knows how to *efficiently* deep copy objects. This means that I track metadata so we can avoid serialize/ deserialize. Anyway, I wanted add this to the common module, because it is a generic service that will be used by several modules (CMP and Cache for now). The problem is common does not build after system, so I can't use ServiceMBeanSupport. Should we add a new module for common services or move the ServiceMBeanSupport stuff to common or something else or should I put my code server? -dain On Monday, March 10, 2003, at 08:15 PM, Dain Sundstrom wrote: I would like to move the org.jboss.invocation.MarshalledValue* to the commons package, so it can be used by non-ejb dependent code. Does any have an issue with this? Does this create a problem for client jars? -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JDK 1.4.1 on OS X out and breaks build
Not working here... I also saw a post about this on the xdoclet list but no response yet. From: Dain Sundstrom [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Tue, 11 Mar 2003 00:13:55 -0600 To: [EMAIL PROTECTED] Subject: [JBoss-dev] JDK 1.4.1 on OS X out and breaks build I just upgraded to 1.4.1 on OS X and now the build won't work. I tried a fresh checkout, but that didn't help. Jason is this working on your mac. -dain bash-2.05a$ java -version java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-39) Java HotSpot(TM) Client VM (build 1.4.1_01-14, mixed mode) bash-2.05a$ ./build.sh build.sh: Executing: /Users/dain/work/jboss/x/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property _buildmagic:init:local-properties: [copy] Copying 1 file to /Users/dain/work/jboss/x/jboss-head/build configure-project: [echo] groups: default [echo] modules: common,naming,remoting,jmx,system,aop,cache,j2ee,management,transaction, persistence,server,blocks,console,security,messaging,connector,varia,clu ster,jetty,jboss.net,iiop _buildmagic:modules:most: == == == Executing 'most' in module 'common'... == == compile-mbean-sources: [mkdir] Created dir: /Users/dain/work/jboss/x/jboss-head/common/output/gen/classes [execmodules] Running mbeaninterface/ [execmodules] Generating output for 'org.jboss.util.property.jmx.SystemPropertyClassValue' using template file 'jar:file:/Users/dain/work/jboss/x/jboss-head/thirdparty/xdoclet- xdoclet/lib/xdoclet-jmx-module-jb4.jar!/xdoclet/modules/jmx/resources/ mbean.xdt'. [execmodules] (XDocletMain.start 51 ) Running XDoclet failed. [execmodules] (XDocletMain.start 52 ) Running XDoclet failed. [execmodules] xdoclet.template.TemplateException: Error in template file: corresponding /XDtClass:classOf not found, line=8 of template file: jar:file:/Users/dain/work/jboss/x/jboss-head/thirdparty/xdoclet- xdoclet/lib/xdoclet-jmx-module-jb4.jar!/xdoclet/modules/jmx/resources/ mbean.xdt [execmodules] at xdoclet.template.TemplateEngine.handleBlockTag(TemplateEngine.java:824) [execmodules] at xdoclet.template.TemplateEngine.handleTag(TemplateEngine.java:425) [execmodules] at xdoclet.template.TemplateEngine.generate(TemplateEngine.java:324) [execmodules] at xdoclet.template.TemplateEngine.start(TemplateEngine.java:373) [execmodules] at xdoclet.TemplateSubTask.startEngine(TemplateSubTask.java:559) [execmodules] at xdoclet.TemplateSubTask.generateForClass(TemplateSubTask.java:765) And so on... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
