RE: [JBoss-dev] Breaking the security module dependency onjboss.transaction.classpath
Ok, we really need an integration library to deal with this and leverage this for the ejb3 cleanup and cleanup the 4.x,5.x codebase dependencies. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Wednesday, January 18, 2006 2:18 AM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] Breaking the security module dependency onjboss.transaction.classpath As per the comment in the code: * @todo this really belongs in some integration layer with * a more pluggable implementation I don't think this belongs in jboss-j2ee.jar since we want to provide a layer that works in all environments including those that have their own j2ee jars. On Wed, 2006-01-04 at 19:52, Scott M Stark wrote: > I see that the security module has become dependent on the transaction > module to support the suspention of the tm in the > DatabaseServerLoginModule. The TransactionDemarcationSupport being used > for this can almost be put into the j2ee module as a utility class as > the majority of its dependencies are jta interfaces. If the > TransactionManagerLocator was updated to bind to the private api via a > system property or other externalized configuration it could be moved > there as well to avoid this. Can we work on cleaning this up? > > > Scott Stark > Chief Technology Officer > JBoss Inc. > > > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&op=click > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBAS-2687
So the simplest fix to this issue: http://jira.jboss.com/jira/browse/JBAS-2687 would seem to be to simply set the TCL to the IdleRemover class loader. More generally we should move this to a work manager task no? Scott StarkVP Architecture & Technology JBoss Inc.
[JBoss-dev] Push to finalizing 3.2.8
Dimitris is going to be driving a finalization of the legacy 3.2.8 release. There still are 11 outstanding issues with several unassigned so he will be contacting the reporters and following up here to get them assigned. The big outstanding integration issue is the targeted binary compatibility between the standard remote interfaces (JMS, ejb transports, webservices). I expect that we need to drill down into these stacks to resolve any incompatibilities that show up. Scott Stark VP Architecture & Technology JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBAS-2687
Agree on the scheduler. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Adrian Brock > Sent: Thursday, January 19, 2006 8:20 AM > To: jboss-development@lists.sourceforge.net > Subject: Re: [JBoss-dev] JBAS-2687 > > The IdleRemover.class.getClassLoader() is the most obvious choice. > The idle removal doesn't really use the classloader anyway. > > More generally: > We should have a system wide "scheduler" with associated > thread pool that can run all these background tasks. > > This "scheduler" should then be externally configurable for > things like thread pool size. > > The advantage of this is that there is only one background > thread in the whole server monitoring when all tasks needs to run. > > Other examples are: > * transaction timeouts > * jbossmq message expiration/scheduled delivery > * jbossmq message softening > * ejb cache invalidation > * security cache invalidation > * etc. > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBAS-1493 for 3.x
It depended on JBAS-2547. I need to review the associated unit test and see if its possible to implement this in 3.2. There is a different run-as principal behavior in 3.2 and no notion of additional run-as roles that would need to be backported as well to fully match the 4.x behavior and I don't know if I want to do this as it would be incompatible with the current behavior. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Dimitris Andreadis > Sent: Friday, January 20, 2006 9:30 AM > To: jboss-development@lists.sourceforge.net > Subject: [JBoss-dev] JBAS-1493 for 3.x > > > Any hints what is required for solving > http://jira.jboss.com/jira/browse/JBAS-1493 by backporting > stuff from 4.x? > > Is http://jira.jboss.com/jira/browse/JBAS-1862?page=vcs the > relevant fix? > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files for problems? Stop! Download the new AJAX > search engine that makes searching your log files as easy as > surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Deprecating oswego in favor of (java.util.concurrent backport?
So all of the retroweavers to date rely on the java.util.concurrent backport to jdk1.4 (http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/) for mapping the jdk5 concurrent util classes. I guess we need to validate this library and deprecate the current Oswego concurrent package in favor of this if its seen to be solid to promote reuse of a common jdk1.4 compatible library. I have not found any stability comparison between the dl.util.concurrent and backport-util-concurrent libraries.
[JBoss-dev] RE: ejb3-4.0-testsuite Build Failed
This is just the org.jboss.ejb3.test.microbench.unit.BenchUnitTestCase requiring too much memory. Memory usage during this test goes from 40m to 130m even using the default config so the memory usage of this needs to be looked at. > -Original Message- > From: Bill Burke > Sent: Sunday, January 15, 2006 7:46 PM > To: Bill Burke > Cc: Scott M Stark; QA; Adrian Brock; Bill Decoste; > jboss-development@lists.sourceforge.net; Kabir Khan; QA; Ruel > Loehr; Thomas Diesler > Subject: Re: ejb3-4.0-testsuite Build Failed > > I should restate. The HA-JNDI multicast crap seems to leak > memory and I have problems with it with a low heap space. > The build-test.xml is looking for a node0.jndi.url and it is > not set by default in local.properties. This is QA's crap. > Ask them about it. > > Bill Burke wrote: > > Looks like the tests are using HA-JNDI's multicast crap. I > also have > > trouble running on 64MB. > > > > Scott M Stark wrote: > > > >> The tests are failing at the point of shutting down the server and > >> I'm seeing this > >> test-with-jvmargs: > >>[delete] Deleting: > >> > /services/cruisecontrol/work/checkout/ejb3-4.0-testsuite/ejb3/output/ > >> log/test.log > >> > >> [junit] Running > org.jboss.ejb3.test.microbench.unit.BenchUnitTestCase > >> [junit] Tests run: 2, Failures: 0, Errors: 3, Time elapsed: > >> 412.146 sec > >> [junit] Test > >> org.jboss.ejb3.test.microbench.unit.BenchUnitTestCase > >> FAILED > >> [echo] Will stop the jboss instance at url > jnp://127.0.0.1:1099 > >> [java] Exception in thread "main" > >> javax.naming.CommunicationException [Root exception is > >> java.rmi.UnmarshalException: Error unmarshaling return > header; nested > >> exception is: [java] java.io.EOFException] > >> [java] at > >> org.jnp.interfaces.NamingContext.lookup(NamingContext.java:722) > >> [java] at > >> org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587) > >> [java] at > >> javax.naming.InitialContext.lookup(InitialContext.java:351) > >> [java] at org.jboss.Shutdown.main(Shutdown.java:214) > >> [java] Caused by: java.rmi.UnmarshalException: Error > unmarshaling > >> return header; nested exception is: [java] > java.io.EOFException > >> [java] at > >> > sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCal > l.java:203) > >> [java] at > sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) > >> [java] at org.jnp.server.NamingServer_Stub.lookup(Unknown > >> Source) > >> [java] at > >> org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625) > >> [java] ... 3 more > >> [java] Caused by: java.io.EOFException > >> [java] at > >> > java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream > >> .java:2232) > >> > >> [java] at > >> > java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputS > >> tream.java:2698) > >> > >> [java] at > >> > java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:750) > >> [java] at > >> java.io.ObjectInputStream.(ObjectInputStream.java:268) > >> [java] at > >> > sun.rmi.server.MarshalInputStream.(MarshalInputStream.java:107) > >> [java] at > >> > sun.rmi.transport.ConnectionInputStream.(ConnectionInputStream. > >> java:38) > >> > >> [java] at > >> > sun.rmi.transport.StreamRemoteCall.getInputStream(StreamRemoteCall.ja > >> va:111) > >> > >> [java] at > >> > sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCal > l.java:197) > >> [java] ... 6 more > >> [java] Java Result: 1 > >> [echo] Waiting for 'all' server to stop... > >> > >> BUILD FAILED > >> > /services/cruisecontrol/work/checkout/ejb3-4.0-testsuite/ejb3/ > build-test.xml:1987: > >> The following error occurred while executing this line: > >> > /services/cruisecontrol/work/checkout/ejb3-4.0-testsuite/ejb3/ > build-test.xml:2008: > >> The following error occurred while executing this line: > >> > /services/cruisecontrol/work/checkout/ejb3-4.0-testsuite/ejb3/ > build-test.
RE: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed
So after profiling this the problem looks to be recent changes in org.jboss.util.timeout.TimeoutFactory as the leaks are related to transaction timeouts. By clearing the TimeoutFactory$TimeoutImpl references the test gets past the OME, but there are 73k TimeoutFactory$TimeoutImpl left after the test has completed and has been undeployed. One gc root is the java.util.TimerThread task queue. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Scott M Stark > Sent: Saturday, January 21, 2006 2:17 PM > To: Bill Burke > Cc: jboss-development@lists.sourceforge.net > Subject: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed > > This is just the org.jboss.ejb3.test.microbench.unit.BenchUnitTestCase > requiring too much memory. Memory usage during this test goes > from 40m to 130m even using the default config so the memory > usage of this needs to be looked at. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed
The issue is that the cancelation of the timer is not removing its association from the java.util.Timer as the TimerTask.cancel just marks the TimerTask.state as cancelled, but its not removed until the timer actually expires. This was leading to a huge list of transaction timeout objects and the associated object graph. Clearing the TimeoutImpl refs in cancel restricts the transient buildup to just the TimeoutImpl. I don't see a way to immeadiate disassociate the TimeoutImpl from the java.util.Timer internals. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Scott M Stark > Sent: Saturday, January 21, 2006 10:12 PM > To: jboss-development@lists.sourceforge.net; Bill Burke > Subject: RE: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed > > So after profiling this the problem looks to be recent > changes in org.jboss.util.timeout.TimeoutFactory as the leaks > are related to transaction timeouts. By clearing the > TimeoutFactory$TimeoutImpl references the test gets past the > OME, but there are 73k TimeoutFactory$TimeoutImpl left after > the test has completed and has been undeployed. One gc root > is the java.util.TimerThread task queue. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Scott M Stark > > Sent: Saturday, January 21, 2006 2:17 PM > > To: Bill Burke > > Cc: jboss-development@lists.sourceforge.net > > Subject: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed > > > > This is just the > org.jboss.ejb3.test.microbench.unit.BenchUnitTestCase > > requiring too much memory. Memory usage during this test > goes from 40m > > to 130m even using the default config so the memory usage of this > > needs to be looked at. > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files for problems? Stop! Download the new AJAX > search engine that makes searching your log files as easy as > surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed
The priority queue should be factored out of the old code and JBAS-2205 reopened as the commits for the current changes do not show up in jira version control tab. Also, the previous author tag was dropped so @author Ole Husgaard needs to be restored. JBAS-2205 has been reopened and this forum for discussion created: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3918930 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Adrian Brock > Sent: Sunday, January 22, 2006 5:49 AM > To: jboss-development@lists.sourceforge.net > Subject: Re: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed > > On Sun, 2006-01-22 at 08:30, Tom Elrod wrote: > > So how should the be addressed when using 1.4? I just > added used of > > Timer for client side leases within remoting. > > > > I think we should reinstate the old code for TimeoutFactory > and add a shutdown method. > > Avoid using java.util.Timer > Even that purge() method has poor performance semantics. > It scans all the registrations everytime. > > > Adrian Brock wrote: > > > 1.5 added a java.util.Timer.purge() > > > > > > I didn't realise Elias had changed TimeoutFactory to use a Timer. > > > He said he was just changing it so it can be used as > something other > > > than a singleton: > > > http://jira.jboss.com/jira/browse/JBAS-2205 > > > > > >>From the cvs commit, it looks like he did this because the > > > old implementation didn't have a "shutdown" method: > > > > http://anoncvs.forge.jboss.com/viewrep/JBoss/jboss-common/src/main/o > > > rg/jboss/util/timeout/TimeoutFactory.java > > > See version 1.4 > > > > > > On Sun, 2006-01-22 at 03:18, Scott M Stark wrote: > > > > > >>The issue is that the cancelation of the timer is not > removing its > > >>association from the java.util.Timer as the TimerTask.cancel just > > >>marks the TimerTask.state as cancelled, but its not removed until > > >>the timer actually expires. This was leading to a huge list of > > >>transaction timeout objects and the associated object graph. > > >>Clearing the TimeoutImpl refs in cancel restricts the transient > > >>buildup to just the TimeoutImpl. I don't see a way to immeadiate > > >>disassociate the TimeoutImpl from the java.util.Timer internals. > > >> > > >> > > >>>-Original Message- > > >>>From: [EMAIL PROTECTED] > > >>>[mailto:[EMAIL PROTECTED] > On Behalf Of > > >>>Scott M Stark > > >>>Sent: Saturday, January 21, 2006 10:12 PM > > >>>To: jboss-development@lists.sourceforge.net; Bill Burke > > >>>Subject: RE: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed > > >>> > > >>>So after profiling this the problem looks to be recent > changes in > > >>>org.jboss.util.timeout.TimeoutFactory as the leaks are > related to > > >>>transaction timeouts. By clearing the TimeoutFactory$TimeoutImpl > > >>>references the test gets past the OME, but there are 73k > > >>>TimeoutFactory$TimeoutImpl left after the test has completed and > > >>>has been undeployed. One gc root is the > java.util.TimerThread task > > >>>queue. > > >>> > > >>> > > >>>>-Original Message- > > >>>>From: [EMAIL PROTECTED] > > >>>>[mailto:[EMAIL PROTECTED] > On Behalf > > >>>>Of Scott M Stark > > >>>>Sent: Saturday, January 21, 2006 2:17 PM > > >>>>To: Bill Burke > > >>>>Cc: jboss-development@lists.sourceforge.net > > >>>>Subject: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed > > >>>> > > >>>>This is just the > > >>> > > >>>org.jboss.ejb3.test.microbench.unit.BenchUnitTestCase > > >>> > > >>>>requiring too much memory. Memory usage during this test > > >>> > > >>>goes from 40m > > >>> > > >>>>to 130m even using the default config so the memory > usage of this > > >>>>needs to be looked at. > > >>> > > >>> > > >>>--- > > >>>This SF.net email is sponsored by: Splunk Inc. Do you > grep through > > >>>log files f
[JBoss-dev] Need closure on the version convention
We need agreement from all projects to accept and adhere to the version conventions discussed here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=75175 Scott Stark VP Architecture & Technology JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: ejb3-4.0-testsuite Build Failed
The current ejb3 testfailure is due to an incomplete integration of the remoting: http://jira.jboss.com/jira/browse/JBAS-2698 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 22, 2006 10:47 AM To: Adrian Brock; Bill Decoste; Bill Burke; Gavin King; jboss-development@lists.sourceforge.net; Kabir Khan; QA; Ruel Loehr; Scott M Stark; Thomas Diesler Subject: ejb3-4.0-testsuite Build Failed Importance: High View results here -> http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite?log=log20060122131732 BUILD FAILED Ant Error Message: /services/cruisecontrol/work/scripts/build-ejb3-4.0-testsuite.xml:83: Exit code: 1 See tests.log in Build Artifacts for details. Date of build: 01/22/2006 13:17:32 Time to build: 28 minutes 56 seconds Last changed: 12/31/2005 16:46:08 Last log entry: call isOpen() when obtaining session so that HEM registers with EM with TXset cglib_use_reflection flag to false
RE: [JBoss-dev] jsr77 stats
It’s a bug, but I only see the MILLISECOND
value being used. I don’t see that javax.management.j2ee.statistics.TimeStatistic
has these constants in the 4.0 branch, so where are you seeing that?
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dimitris Andreadis
Sent: Tuesday, January 24, 2006
5:27 AM
To:
jboss-development@lists.sourceforge.net
Subject: [JBoss-dev] jsr77 stats
I've noticed (4.x/HEAD)
org.jboss.management.j2ee.StatisticsConstants.HOUR is actually "MILLISECOND"
Is that a bug or a feature :)
...
public final class
StatisticsConstants
{
public static final String HOUR = "MILLISECOND";
public static final String MINUTE = "MINUTE";
...
In fact, there is javax.management.j2ee.statistics.TimeStatistic
the has those constants, why replicate them?
RE: [JBoss-dev] Example of how careless handling of AOP pointcut expressions can screw you up good
I would suspect that the tests simply asserted that someone could be denied access. This is a general failing in the tests I see written. Tests only assert that the expected good things happen. There are not enough tests written to validate that bad behaviors are also constrained to expected and recoverable behaviors. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ovidiu Feodorov Sent: Friday, January 27, 2006 11:44 AM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] Example of how careless handling of AOP pointcut expressions can screw you up good A succinct example of how AOP pointcut expressions without proper tests and/or compile-time check tools can screw you up good: JMS lets you create anonymous message producers, and for this case, security checks must be applied on each message send. The following pointcut expression enforces that: Recently, the ProducerAdvised's send() method name and signature has been changed upon a refactoring: $ cvs diff -r 1.3 -r 1.2 ProducerAdvised.java Index: ProducerAdvised.java === RCS file: /cvsroot/jboss/jboss-jms/src/main/org/jboss/jms/server/endpoint/advised/ ProducerAdvised.java,v retrieving revision 1.3 retrieving revision 1.2 diff -r1.3 -r1.2 ... 68c69public void send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive) throws JMSException ... As result, no security checks were applied anymore on individual message sends for anonymous producers, leading to a very silent, subtle and potentially dangerous error condition. Praises to Tim for adding test cases that helped us catch the problem on our work benches and not in some customer's production environment. Can the Eclipse AOP plugin help in catching this type of error at refactoring time? Ovidiu --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Maven2 technical discussion
What happened to the webex? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Julien Viet Sent: Friday, January 27, 2006 4:21 PM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] Maven2 technical discussion We had a presentation of Maven 2 build of JBoss during a qa conf call for Portal. http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3920134#3920134 We would like to migrate as soon as possible. Ruel Loehr wrote: > > > I'm setting up a web-ex for later this week (wed or thurs) in which I > will present a Maven2 build implementation for JBoss. > > This presentation will consist of walking through the build files and > discussing how the build works, as well as features and drawbacks. > > > > In order to include as many interested parties as possible, please reply > to me if interested. I will setup a time that accommodates as many > people as possible. > > > > Thanks! > > > > Ruel Loehr > > JBoss QA > > > > > > > -- Julien Viet JBoss Portal Project Lead ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: jboss-4.0-jdk-matrix Build Failed
I’m working through getting these in synch. From: Ryan Campbell Sent: Saturday, January 28, 2006 9:51 AM To: jboss-development@lists.sourceforge.net; Scott M Stark Subject: RE: jboss-4.0-jdk-matrix Build Failed Strange errors on the build machine (checking these), but I’m getting the following build error on clean checkout of jboss-4.0.x /home/rcampbell/tmp/jboss-4.0.x/build/build.xml:913: The following error occurred while executing this line: /home/rcampbell/tmp/jboss-4.0.x/build/build-thirdparty.xml:124: A versioning problem exists: Component: hibernate is at version: 3.1.2 but it is also required to be compatible with: [EMAIL PROTECTED], version=3.1.1}] by: hibernate-annotations From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 28, 2006 11:10 AM To: jboss-development@lists.sourceforge.net; QA; Scott M Stark Subject: jboss-4.0-jdk-matrix Build Failed Importance: High View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-jdk-matrix?log=log20060128115204 BUILD FAILED Ant Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:216: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:50: Exit code: 1 See compile.log in Build Artifacts for details. Date of build: 01/28/2006 11:52:04 Time to build: 14 minutes 13 seconds Last changed: 01/28/2006 11:19:11 Last log entry: JBAS-2707, update to hibernate 3.1.2 Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 1) 1.1.2.68 modified starksm build/build-thirdparty.xml JBAS-2707, update to hibernate 3.1.2
[JBoss-dev] RE: jboss-4.0-jdk-matrix Build Failed
Its building for me now. From: Ryan Campbell Sent: Saturday, January 28, 2006 9:51 AM To: jboss-development@lists.sourceforge.net; Scott M Stark Subject: RE: jboss-4.0-jdk-matrix Build Failed Strange errors on the build machine (checking these), but I’m getting the following build error on clean checkout of jboss-4.0.x /home/rcampbell/tmp/jboss-4.0.x/build/build.xml:913: The following error occurred while executing this line: /home/rcampbell/tmp/jboss-4.0.x/build/build-thirdparty.xml:124: A versioning problem exists: Component: hibernate is at version: 3.1.2 but it is also required to be compatible with: [EMAIL PROTECTED], version=3.1.1}] by: hibernate-annotations From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 28, 2006 11:10 AM To: jboss-development@lists.sourceforge.net; QA; Scott M Stark Subject: jboss-4.0-jdk-matrix Build Failed Importance: High View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-jdk-matrix?log=log20060128115204 BUILD FAILED Ant Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:216: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:50: Exit code: 1 See compile.log in Build Artifacts for details. Date of build: 01/28/2006 11:52:04 Time to build: 14 minutes 13 seconds Last changed: 01/28/2006 11:19:11 Last log entry: JBAS-2707, update to hibernate 3.1.2 Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 1) 1.1.2.68 modified starksm build/build-thirdparty.xml JBAS-2707, update to hibernate 3.1.2
[JBoss-dev] RE: Restore DeploymentRolesLoginModule
What tests depend on this login module? As I remember only the run-as capability needed to augment the roles and this does not require a login module to do this. From: Thomas Diesler Sent: Monday, January 30, 2006 4:16 AM To: Scott M Stark Cc: 'jboss-development@lists.sourceforge.net' Subject: RE: Restore DeploymentRolesLoginModule I did not realize the server module now depends on security. I rolled back the module dependency and try to refactor such that DeploymentRolesLoginModule does not depend on server meta data From: Thomas Diesler Sent: Monday, January 30, 2006 11:18 To: Scott M Stark Cc: 'jboss-development@lists.sourceforge.net' Subject: Restore DeploymentRolesLoginModule Scott, I restored the DeploymentRolesLoginModule and its associated dependency to the server module because various CTS tests depend on this login module. The comment now reads: /** * The DeploymentRolesLoginModule adds the roles to the subject that were declared in the * assembly-descriptor element in jboss.xml. * * * * * * * * * This allows dynamic role assignment to a given principal per EJB jar deployment. * Used by EJB jar deployments in the CTS. Cheers -thomas Revision : 1.1.6.2 Date : 2006/1/14 6:38:48 Author : 'starksm' State : 'dead' Lines : +2 -2 Description : Remove the unsupported/documented DeploymentRolesLoginModule Revision : 1.51.2.10 Date : 2006/1/14 6:50:56 Author : 'starksm' State : 'Exp' Lines : +1 -5 Description : JBAS-2359, refactor security classes out of the server module to security module
[JBoss-dev] RE: Restore DeploymentRolesLoginModule
This does not mean this is where we need to be picking up these roles from. Create a jira issue with the failing tests as I really thought I had eliminated the need for the DeploymentRolesLoginModule when I last when through the security portion of the cts. From: Thomas Diesler Sent: Monday, January 30, 2006 4:52 AM To: Scott M Stark Cc: 'jboss-development@lists.sourceforge.net' Subject: RE: Restore DeploymentRolesLoginModule There are various tests that define a role mapping in sun-ejb-jar.xml. These roles are mapped to jboss.xml like this A search found 98 sun-ejb-jar.xml files with that mapping. xxx Thomas Diesler Web Service Lead JBoss Inc. xxx From: Scott M Stark Sent: Monday, January 30, 2006 13:43 To: Thomas Diesler Cc: 'jboss-development@lists.sourceforge.net' Subject: RE: Restore DeploymentRolesLoginModule What tests depend on this login module? As I remember only the run-as capability needed to augment the roles and this does not require a login module to do this. From: Thomas Diesler Sent: Monday, January 30, 2006 4:16 AM To: Scott M Stark Cc: 'jboss-development@lists.sourceforge.net' Subject: RE: Restore DeploymentRolesLoginModule I did not realize the server module now depends on security. I rolled back the module dependency and try to refactor such that DeploymentRolesLoginModule does not depend on server meta data From: Thomas Diesler Sent: Monday, January 30, 2006 11:18 To: Scott M Stark Cc: 'jboss-development@lists.sourceforge.net' Subject: Restore DeploymentRolesLoginModule Scott, I restored the DeploymentRolesLoginModule and its associated dependency to the server module because various CTS tests depend on this login module. The comment now reads: /** * The DeploymentRolesLoginModule adds the roles to the subject that were declared in the * assembly-descriptor element in jboss.xml. * * * * * * * * * This allows dynamic role assignment to a given principal per EJB jar deployment. * Used by EJB jar deployments in the CTS. Cheers -thomas Revision : 1.1.6.2 Date : 2006/1/14 6:38:48 Author : 'starksm' State : 'dead' Lines : +2 -2 Description : Remove the unsupported/documented DeploymentRolesLoginModule Revision : 1.51.2.10 Date : 2006/1/14 6:50:56 Author : 'starksm' State : 'Exp' Lines : +1 -5 Description : JBAS-2359, refactor security classes out of the server module to security module
RE: [JBoss-dev] Keeping installer templates in-synch
We had this discussion in a forum and came to no conclusion as to how to ensure these are kept in synch. What is clearly needed is running portions of the testsuite against the installer generated configurations. Some work to run the installer in a command line mode will be needed for this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Monday, January 30, 2006 4:57 AM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] Keeping installer templates in-synch The problem here is the old one of trying to build things on top of other things. If you have no buy-in to the process from your providers you are left trying to hit a moving a target. Solutions: 1) Make it easy for people to maintain it 2) Write tests so you know when it breaks 3) Make it a more first class construct such that developers can "automagically" maintain it or at least know early when it is affected. 4) "Lock down" the provider's config and complain when they change it without notifying you. On Mon, 2006-01-30 at 07:48, Dimitris Andreadis wrote: > Somehow we need to do a better job keeping the installer xml > descriptor templates in-synch with the module xml descriptors, so > whenever a descriptor changes the template needs updating. > > I just fixed a trivial one, probably my bad: > http://jira.jboss.com/jira/browse/JBAS-2742 > > The other thing we need to clarify is whether the installer > distribution is the "recommended" one, since more cases (forums / > support) will start appearing where we are not sure about the used > (user/customer) config. -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Restore DeploymentRolesLoginModule
As we talked about when going through the cts originally, I view the deployment descriptor roles as useful only for run-as behavior. Every other security deployment needs to use the security domain configuration mechanism. We do not need to be dynamically generating this info on a deployment basis from the proprietary sun descriptor. The user to role mappings are defined up front in the cts guide. I would guess this should just work using the existing UserRolesLoginModule and the cts security-domain with its associated cts-users.properties/cts-roles.properties. Why the DeploymentRolesLoginModule has to be in this login-config.xml section is the question. From: Thomas Diesler Sent: Monday, January 30, 2006 5:17 AM To: Scott M Stark Cc: 'jboss-development@lists.sourceforge.net' Subject: RE: Restore DeploymentRolesLoginModule For this to be tested the DeploymentRolesLoginModule needs to be removed from login-config.xml in the cts configuration. I had ~70 tests failing in module jaxrpc/webservice because of ClassNotFoundException. How do you suggest to handle the role/principal mapping in sun-ejb-jar.xml if not through in jboss.xml? Is there a way to pickup that mapping from jboss.xml other than through the DeploymentRolesLoginModule? I assume you want to keep that functionality in jboss_4_0.dtd. -thomas From: Scott M Stark Sent: Monday, January 30, 2006 14:03 To: Thomas Diesler Cc: 'jboss-development@lists.sourceforge.net' Subject: RE: Restore DeploymentRolesLoginModule This does not mean this is where we need to be picking up these roles from. Create a jira issue with the failing tests as I really thought I had eliminated the need for the DeploymentRolesLoginModule when I last when through the security portion of the cts. From: Thomas Diesler Sent: Monday, January 30, 2006 4:52 AM To: Scott M Stark Cc: 'jboss-development@lists.sourceforge.net' Subject: RE: Restore DeploymentRolesLoginModule There are various tests that define a role mapping in sun-ejb-jar.xml. These roles are mapped to jboss.xml like this A search found 98 sun-ejb-jar.xml files with that mapping. xxx Thomas Diesler Web Service Lead JBoss Inc. xxx From: Scott M Stark Sent: Monday, January 30, 2006 13:43 To: Thomas Diesler Cc: 'jboss-development@lists.sourceforge.net' Subject: RE: Restore DeploymentRolesLoginModule What tests depend on this login module? As I remember only the run-as capability needed to augment the roles and this does not require a login module to do this. From: Thomas Diesler Sent: Monday, January 30, 2006 4:16 AM To: Scott M Stark Cc: 'jboss-development@lists.sourceforge.net' Subject: RE: Restore DeploymentRolesLoginModule I did not realize the server module now depends on security. I rolled back the module dependency and try to refactor such that DeploymentRolesLoginModule does not depend on server meta data From: Thomas Diesler Sent: Monday, January 30, 2006 11:18 To: Scott M Stark Cc: 'jboss-development@lists.sourceforge.net' Subject: Restore DeploymentRolesLoginModule Scott, I restored the DeploymentRolesLoginModule and its associated dependency to the server module because various CTS tests depend on this login module. The comment now reads: /** * The DeploymentRolesLoginModule adds the roles to the subject that were declared in the * assembly-descriptor element in jboss.xml. * * * * * * * * * This allows dynamic role assignment to a given principal per EJB jar deployment. * Used by EJB jar deployments in the CTS. Cheers -thomas Revision : 1.1.6.2 Date : 2006/1/14 6:38:48 Author : 'starksm' State : 'dead' Lines : +2 -2 Description : Remove the unsupported/documented DeploymentRolesLoginModule Revision : 1.51.2.10 Date : 2006/1/14 6:50:56 Author : 'starksm' State : 'Exp' Lines : +1 -5 Description : JBAS-2359, refactor security classes out of the server module to security module
[JBoss-dev] MC/AOP consistency synch in progress yet?
Adrian, Have you had a chance to synch up with Kabir on the MC/AOP unification work yet?
[JBoss-dev] EJB3StandaloneBootstrap implementation
I browsed through the EJB3StandaloneBootstrap and embedded ejb3 usage of the mc to see what extent the mc is being used. In browsing through the conf/embedded-jboss-beans.xml for the mc config, I did not see anything related to the ejb3 container or aop layer to load the conf/ejb3-interceptors-aop.xml. The embedded ejb3 docs show this prototype code block for setting up embedded ejb3: EJB3StandaloneBootstrap.boot(null); // initialize JBoss MQ core services EJB3StandaloneBootstrap.deployXmlResource("jboss-jms-beans.xml"); // initialize configured test queue and topic EJB3StandaloneBootstrap.deployXmlResource("testjms.xml"); // scan classpath for ejbs and MDBs EJB3StandaloneBootstrap.scanClasspath(); So a lot of configuration is being done outside of the mc embedded-jboss-beans.xml. I guess this is due to missing implementation details of the mc such as the vfs, virtual deployment impl, and class loader configuration. I have been thinking about how to push the mc forward by getting it more into jboss5, but maybe using the embedded ejb3 setup would be a less disruptive way to drive these features to completion. Does it make sense to organize the next set of mc releases around getting the embedded ejb3 completely configured from a prototype standalone mc bootstrap (http://docs.jboss.org/nightly/microkernel/docs/gettingstarted/en/html/standalone.html) which loads a more complete embedded-ejb3-beans.xml that includes the ejb3 container and aop configuration?
RE: [JBoss-dev] EJB3StandaloneBootstrap implementation
How can the scanClasspath() step be optimized/skipped in say an embedded
ejb3 project in jbosside where the data obtained during the scan was
written out in an optimized metadata store as part of the project say?
I don't really follow adding aspects like clustering to deployments
based on the location in a filesystem, virtual or otherwise. Just seems
like too much meaning being linked to the deployment url/location.
I'm busy through tomorrow, but come thu I will just checkin the current
vfs stuff I have had sitting in the workspace for months and see what
start can be made on pushing this forward.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill
Burke
Sent: Tuesday, January 31, 2006 9:28 AM
To: jboss-development@lists.sourceforge.net
Subject: Re: [JBoss-dev] EJB3StandaloneBootstrap implementation
I think going the E-EJB3 route to start is a good idea as it will force
us to implement bare-bones implementations that do not have the idea of
a classloader or j2ee deployment schemes within them. Once we have
e-ejb3 (really e-jboss) in place, it will force us to be careful about
adding things like classloading and j2ee packaging as to not break or
bloat e-jboss.
The way I envision it working is basically how it works with current
kernel
* This shit must be REALLY FAST. Remember, we're using it with junit
tests.
* embedded-jboss-beans.xml configures a MainDeployer, BeanDeployer,
AOPDeployer, EJB3Deployer, (etc.) and basic services like TM, JNDI, etc.
* EJB3StandaloneBootstrap still exists and has three methods:
- boot(): This loads embeddded-jboss-beans.xml
- scanClasspath(). The scans the entire classpath for deployments and
calls MainDeployer.deploy() for each jar/directory/config file it finds.
calling MainDeployer.deploy(URL).
- scanClasspath(String) comma delimited list of files that should be
deployed. These files are in the classpath (java.class.path)
- deployResource(String) deploys an individual Classpath resource.
("ejb3-interceptors-aop.xml") by calling MainDeployer.deploy(URL)
My second thought is that Scanners should be responsible for creating
the DeploymentUnit rather than the main deployer. This will allow the
scanner to add metadata about the deployment or to work with different
"filesystems", like a database or profile. For instance, I envision a
cluster/ directory where any deployment put in it that supports
clustering will be clustered. The scanner could also be configured for
default security domain. For this to work, the scanner needs to attach
metadata to the deploymentunit. Since the MainDeployer will not be
responsible for creating the deployment unit, this will make it easier.
If you look at the EJB3 code, you will also find that I have done a
kernel abstraction so that the EJB3 deployer and codebase does not have
to be concerned about whether you are deployment to JBoss4 or MC. If we
do the new deployers right, the new architecture can be used as an
abstraction for projects that need to work in both JBoss4 and MC.
Man, I want to help prototype this stuff. I was about to do it for the
last EJB3 release, but I ran out of time. I'll want to jump in and help
after I finish the EJB3 book.
Later,
Bill
Scott M Stark wrote:
> I browsed through the EJB3StandaloneBootstrap and embedded ejb3 usage
of the mc to see what extent the mc is being used. In browsing through
the conf/embedded-jboss-beans.xml for the mc config, I did not see
anything related to the ejb3 container or aop layer to load the
conf/ejb3-interceptors-aop.xml. The embedded ejb3 docs show this
prototype code block for setting up embedded ejb3:
>
>
>
> EJB3StandaloneBootstrap.boot(null);
>
> // initialize JBoss MQ core services
>
>
EJB3StandaloneBootstrap.deployXmlResource("jboss-jms-beans.xml");
>
> // initialize configured test queue and topic
>
> EJB3StandaloneBootstrap.deployXmlResource("testjms.xml");
>
> // scan classpath for ejbs and MDBs
>
> EJB3StandaloneBootstrap.scanClasspath();
>
>
>
> So a lot of configuration is being done outside of the mc
embedded-jboss-beans.xml. I guess this is due to missing implementation
details of the mc such as the vfs, virtual deployment impl, and class
loader configuration. I have been thinking about how to push the mc
forward by getting it more into jboss5, but maybe using the embedded
ejb3 setup would be a less disruptive way to drive these features to
completion.
>
>
>
> Does it make sense to organize the next set of mc releases around
getting the embedded ejb3 completely configured from a prototype
standalone mc bootstrap
(http://docs.jboss.org/nightly/microkernel/docs/gettingstarted/en/html/s
tandalone.html) which loads a more complete embedded-ejb3-beans.xml that
includes the ejb3 container and aop co
RE: [JBoss-dev] EJB3StandaloneBootstrap implementation
I'm saying the ide should be creating the optimized metadata view as the project evolves. Of course this is an optional behavior. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Wednesday, February 01, 2006 10:13 AM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] EJB3StandaloneBootstrap implementation Scott M Stark wrote: > How can the scanClasspath() step be optimized/skipped in say an embedded > ejb3 project in jbosside where the data obtained during the scan was > written out in an optimized metadata store as part of the project say? > The definition of embedded is *simple*. This optimized metadata store should be an optional feature. We don't want to require the user to have a special directory structure or special configuration requirements other than putting stuff in the classpath. Also, in an IDE environment an optimized metadata store doesn't make much sense since users are recompiling, repackaging with each run. IMO, a scan to create an optimized metadata store does not improve development time, its just overhead. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: Guessing datasource name
I still think we need a jmx object name alias registry to wean off of the objectnames to simple, purpose oriented names. This would have to be integrated as an aspect on top of the mbeanserver/registry. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Wednesday, February 01, 2006 12:59 PM To: jboss-development@lists.sourceforge.net Cc: Bill Burke Subject: Re: [JBoss-dev] Re: Guessing datasource name Perhaps we should just byte the bullet and fix this naming confusion? The problem is everybody's existing config that uses it. e.g. JMS and login-config.xml that reference these names. You can certainly "fix" the stylesheet and change this config in jbossjca-service.xml -ds.xml 300:-ds.xml stylesheets/ConnectionFactoryTemplate.xsl false --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Generic Embedded/Bootstrap was RE: [JBoss-dev] EJB3StandaloneBootstrap implementation
This will help get us finalized on a mc and start thinking about the proper abstractions to use it so I'm all for it. 1) Some have been inquiring about whether spring integration setups can also be used. Possibly we could have a spring alias mapping that binds to our integration implementation. Possibly we could even use existing spring integration objects for standard apis like JTA so we don't have to write it for envs we don't readily have for testing. 2) So you are talking about abstractions on top of JTA or on the JTA provider service for interaction outside of JTA? 3) Good. As a part-time dev on the kernel its hard for me to pull all of the pieces together with respect to a usable mc setup so I think a concrete collection of components in an embedded type of profile will help finalize the design. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Wednesday, February 01, 2006 4:57 AM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] Generic Embedded/Bootstrap was RE: [JBoss-dev] EJB3StandaloneBootstrap implementation FYI I am starting work on a prototype of the following three new modules (I am not sure these are good names :-) 1) Integration - Cross (other) container integration spi like "how do I bind to jndi?", give me the transaction synchronizer, etc. 2) Services - abstraction of our common container spi, such that other projects can use these interfaces to talk to each other rather than linking directly to implementation e.g. Who knows whether the user wants to use JBossJTA or JBoss Transactions? 3) Embedded - an extension to the kernel module that introduces aop, jmx, profile service and eventually aspectized deployments (all optional) My plans for enhanced embedded bootstrap implementations are: * Explicit - tell me what you want to do - suitable for extension * Classpath - like current MC Standalone bootstrap - suitable for main() usage * "URLClassLoader" - parse getURLs() and look for config relative to this - suitable for running inside an EJB container, servlet container, etc. * Test - shared base common config + test specific config - suitable for use in JUnit/TestNG I think this has some redundancy with the EJB3 bootstrap methods but it doesn't make sense to have this EJB3 specific. e.g. I want to * bootstrap/configure some JBoss Service inside a servlet context of another JEE container * run tests against a service that requires other services * provide a real standalone distribution of JBoss Messaging * etc. My motivation for this prototype is not to get a product out of it yet. It is to flush out the integration details between the projects. In particular, AOP and MC. I started the new jca project for this purpose as well, but I haven't had any real feedback on this prototype from the AOP team. It also includes a simple AOP proxy replacement for org.jboss.proxy in the aspects module (again a prototype) and POJOs to allow aspects to be configured via DI in the MC. Bill did help me with some pointcut definition enhancements to implement MessageEndpoint properly. I'm hoping if I do this for something less esoteric than JCA then I will get some feedback ;-) On Tue, 2006-01-31 at 22:26, Scott M Stark wrote: > How can the scanClasspath() step be optimized/skipped in say an embedded > ejb3 project in jbosside where the data obtained during the scan was > written out in an optimized metadata store as part of the project say? > > I don't really follow adding aspects like clustering to deployments > based on the location in a filesystem, virtual or otherwise. Just seems > like too much meaning being linked to the deployment url/location. > > I'm busy through tomorrow, but come thu I will just checkin the current > vfs stuff I have had sitting in the workspace for months and see what > start can be made on pushing this forward. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bill > Burke > Sent: Tuesday, January 31, 2006 9:28 AM > To: jboss-development@lists.sourceforge.net > Subject: Re: [JBoss-dev] EJB3StandaloneBootstrap implementation > > I think going the E-EJB3 route to start is a good idea as it will force > us to implement bare-bones implementations that do not have the idea of > a classloader or j2ee deployment schemes within them. Once we have > e-ejb3 (really e-jboss) in place, it will force us to be careful about > adding things like classloading and j2ee packaging as to not break or > bloat e-jboss. > > The way I envision it working is basically how it works with current > kernel > > * This shit must be REALLY FAST. Remember, we're using it with junit > tests. > * embedded-jboss-beans.xml configures a MainDeployer, BeanDeployer, > AOPDeployer, EJB3D
[JBoss-dev] RE: 3.2.x / 4.0.x compatibility
Yes, it should be conditionally enabled. This was added to deal with hash collisions due to calculations that were not considering the interface/class of the method. -Original Message- From: Dimitris Andreadis Sent: Thursday, February 02, 2006 11:13 AM To: jboss-development@lists.sourceforge.net Cc: Scott M Stark Subject: 3.2.x / 4.0.x compatibility One of the differences I see in the 2 branches, is the useFullHashMode: org.jboss.invocation.MarshalledInvocation /** A flag indicating if the */ static boolean useFullHashMode = false; Which was added around 3.2.4 http://sourceforge.net/docman/display_doc.php?docid=21888&group_id=22866 This is 'true' for 4.0.x thus prohibiting interoperability and I don't see this being configured somewhere. Can I conditionally set this to true, based only the org.jboss.util.id.SerialVersion.version setting? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Make sure you include the jira issue number in cvs checkins
Also make sure the jira issue number is used in the check in all branches so that the branches the changes have been committed to are clear from the issue version control tab. -Original Message- From: Scott M Stark Sent: Thursday, February 02, 2006 3:54 PM To: 'jboss-development@lists.sourceforge.net' Subject: Make sure you include the jira issue number in cvs checkins Make sure you include the jira issue number for any checkins related to a jira issue so that the changes associated with the issue show up in the Version Control tab of the issue. It also aides in correlating cvs log messages with jira issues. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Make sure you include the jira issue number in cvs checkins
Make sure you include the jira issue number for any checkins related to a jira issue so that the changes associated with the issue show up in the Version Control tab of the issue. It also aides in correlating cvs log messages with jira issues. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Make sure you include the jira issue number in cvs checkins
I have been asked to also remind you that a useful comment also be included in each change set since there can be a disconnect between what shows up in the jira issue vs the individual file changes. Scott M Stark wrote: > Make sure you include the jira issue number for any checkins related to > a jira issue so that the changes associated with the issue show up in > the Version Control tab of the issue. It also aides in correlating cvs > log messages with jira issues. > > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] cglib vs javassit for proxies
So I have to introduce a proxy for a javax.net.SSLServerSocket which is an abstract class and so have to use cglib or javassist. I see some proxy working in the head javassist, but this is not in the 4.0 branch version. We also don’t bundle javassist with 4.0 currently. I assume we would rather have javassist be the only bytecode manipulation framework in jboss. Is there a timeframe for completing the javassist proxy so we can think about moving hibernate, webservices, cmp2.x, etc over to it?
RE: [JBoss-dev] BasicThreadPool and Thread.stop()
It was the only way I found to implement a timeout behavior that had a chance of working when there were uncooperative tasks. See the org.jboss.test.util.test. ThreadPoolTaskUnitTestCase.testCompleteTimeoutWithSpinLoop as an example. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Saturday, February 04, 2006 2:33 PM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] BasicThreadPool and Thread.stop() I don't think it is a good idea to invoke Thread.stop(). This has memory leak problems. Why was this introduced? The pooled threads are already daemon threads so they should not stop the system from exiting at shutdown. If you are not shutting down the system, then any objects on the stopped thread's stack are not garbage collected. -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Legacy xml config parsing
I have a need to externalize some configuration on a new security related interceptor and don't want to propagate the old XmlLoadable interface, even though it's the only way to do this currently. I could adapt some of the service xml support configuration mechanisms like serialDataType="javaBean | jbxb" (see http://wiki.jboss.org/wiki/Wiki.jsp?page=SERVICEdotXML), but introducing this piecewise for all of the extension points in the requires mods to many layers due to the XmlLoadable coupling configuration to implementation layers. Anyone looked at trying to unify the legacy jboss.xml parsing into a jbossxb implementation that would help with this? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Legacy xml config parsing
The simple immediate solution would be to take all of the interceptor attributes as string key/value pairs for java bean style properties that are passed to the org.jboss.util.propertyeditor.PropertyEditors.mapJavaBeanProperties similar to the handling in the service configuration for serialDataType="javaBean". -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Sunday, February 05, 2006 1:05 PM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] Legacy xml config parsing I have a need to externalize some configuration on a new security related interceptor and don't want to propagate the old XmlLoadable interface, even though it's the only way to do this currently. I could adapt some of the service xml support configuration mechanisms like serialDataType="javaBean | jbxb" (see http://wiki.jboss.org/wiki/Wiki.jsp?page=SERVICEdotXML), but introducing this piecewise for all of the extension points in the requires mods to many layers due to the XmlLoadable coupling configuration to implementation layers. Anyone looked at trying to unify the legacy jboss.xml parsing into a jbossxb implementation that would help with this? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Looks like the win32 file limit issue is fixed in jdk1.5.0_06
The internal api used by the jdk looks to have been updated to allow for 32k file paths rather than the current 255 char limit: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182812
[JBoss-dev] JAXBException serialVersionUID mismtach with j2ee.14
Somehow we seem to have missed synching the javax.xml.bind.JAXBException
class serialVersionUID up with the j2ee1.4 value when we aligned these
in 4.0.2.
WARNING: No explicit serialVersionUID:
ClassVersionInfo{serialVersion=4092921986583236256,
hasExplicitSerialVersionUID=false, name=javax.xml.bind.JAXBException}
serialVersionUID error for javax.xml.bind.JAXBException, J2EE1.4
-1795805848732208234, current: 4092921986583236256
I rechecked the current j2ee1.4 ri value and it is consistent with the
testsuite serialVersionUID/j2ee141.ser value:
[EMAIL PROTECTED] lib]$ serialver -classpath jaxr-impl.jar
javax.xml.bind.JAXBException
javax.xml.bind.JAXBException:static final long serialVersionUID =
-1795805848732208234L;
We can use the org.jboss.j2ee.LegacySerialization system property to
correct this, but the check against the serialVersionUID/402.ser will
then fail and the JAXBException would have to be excluded from the
check, or the serialVersionUID/402.ser updated.
The big issue here is that I don't see how the
org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase passed
for the past releases. We can't have this test pass and latter have an
incompatibility like this show up. Either there is a flaw in the test or
what I'm seeing so I need to figure this out before 4.0.4RC1 goes out.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Do antlr exception leak to users?
I’m seeing some incompatible serial version uid changes in the latest antlr, but I don’t know if antlr exceptions every leak to users outside of the vm such that this is an issue. Do the ql grammar exception get exposed or are they always converted to a hibernate exception? serialVersionUID error for antlr.ANTLRException, 402 7031854369222456415, current: -3185796504902623848 serialVersionUID error for antlr.TokenStreamException, 402 -6645096224442002282, current: -8659971349776228514
[JBoss-dev] RE: JAXBException serialVersionUID mismtach with j2ee.14
javax.xml.bind.* and jaxb are not part of j2ee1.4 even though the ri
happens to include them so this is actually fine. The serialVersionUID
has been set to the j2ee1.4 value.
-Original Message-
From: Scott M Stark
Sent: Monday, February 06, 2006 11:27 AM
To: jboss-development@lists.sourceforge.net
Cc: '[EMAIL PROTECTED]'
Subject: JAXBException serialVersionUID mismtach with j2ee.14
Somehow we seem to have missed synching the javax.xml.bind.JAXBException
class serialVersionUID up with the j2ee1.4 value when we aligned these
in 4.0.2.
WARNING: No explicit serialVersionUID:
ClassVersionInfo{serialVersion=4092921986583236256,
hasExplicitSerialVersionUID=false, name=javax.xml.bind.JAXBException}
serialVersionUID error for javax.xml.bind.JAXBException, J2EE1.4
-1795805848732208234, current: 4092921986583236256
I rechecked the current j2ee1.4 ri value and it is consistent with the
testsuite serialVersionUID/j2ee141.ser value:
[EMAIL PROTECTED] lib]$ serialver -classpath jaxr-impl.jar
javax.xml.bind.JAXBException
javax.xml.bind.JAXBException:static final long serialVersionUID =
-1795805848732208234L;
We can use the org.jboss.j2ee.LegacySerialization system property to
correct this, but the check against the serialVersionUID/402.ser will
then fail and the JAXBException would have to be excluded from the
check, or the serialVersionUID/402.ser updated.
The big issue here is that I don't see how the
org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase passed
for the past releases. We can't have this test pass and latter have an
incompatibility like this show up. Either there is a flaw in the test or
what I'm seeing so I need to figure this out before 4.0.4RC1 goes out.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBossProductVersioning update
I have not seen any outcry over the version convention thread so I have updated the product version page to summarize the conclusion reached. Getting projects aligned to this convention is something all leads need to work on. http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning Scott Stark VP Architecture & Technology JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossProductVersioning update
It cannot be resolved as a version in between a Beta and GA release using the osgi bundle version comparision as discussed in this thread. http://www.jboss.com/index.html?module=bb&op=viewtopic&t=75175 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Burke > Sent: Tuesday, February 07, 2006 9:20 AM > To: jboss-development@lists.sourceforge.net > Subject: Re: [JBoss-dev] JBossProductVersioning update > > Any reason we can't keep the RC instead of switching to CR? > They mean the same and we've been using RC for, what, years? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [Hibernate] Release naming conventions
Any place the version is actually used. This is the manifest headers (these should also be spelled out and standardized including the osgi conventions for projects that need to comply with these headers), the repository component-info.xml, and the project build files. Really only the project build file should be where a project makes version changes and this should just propagated to artifacts based on the build tools. > -Original Message- > From: Max Andersen > Sent: Tuesday, February 07, 2006 10:14 AM > To: Scott M Stark; Christian Bauer; development Hibernate; > [EMAIL PROTECTED] > Subject: Re: [Hibernate] Release naming conventions > > > so where do you want the name applied ? > > in the eclipse plugins it make sense for the jar's since that > is the part being used to identify it + the > plugin.xml/MANIFEST.MF osgi version part. > > /max > > > This has nothing to do with the actual jar names. The > version in the > > jar name is a poor convention as it propagates the version to users > > unnecessarily, and is not verifiable via a signed manifest. > The jars > > checked into the repository should not have any explicit version > > information in the name. I don't care what naming > conventions are used > > by projects elsewhere. > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On > Behalf Of Max > >> Rydahl Andersen > >> Sent: Tuesday, February 07, 2006 10:01 AM > >> To: Christian Bauer; development Hibernate; > >> [EMAIL PROTECTED] > >> Subject: Re: [Hibernate] Release naming conventions > >> > >> >> > >> >> I'm not a big fan of all minor releases needing to append > >> '.ga' (i.e. > >> >> 3.1.3.ga.jar). I really wish there was a way to define > ordering > >> >> amongst "qualifiers". > >> > > >> > AFAIK these conventions are for package names and not > necessarily > >> > library names? > >> > >> it's the version branded into the application - meaning what goes > >> into MANIFEST.MF and distribution name; for me it would > make sense to > >> have that on the jar file too... > >> > >> And yes, would be great with an "ordering" that said 3.1.3 > is "newer" > >> than 3.1.3.alpha, 3.1.3.beta..but what is 3.1.3.2 then ? > >> > >> p.s. i'm planning on following this in the eclipse plugins > too since > >> it actually is very usefull there to have the update manager > >> functionallity work together with alpha/beta/etc. > >> > >> /max > >> > >> > > >> > --- > >> > This SF.net email is sponsored by: Splunk Inc. Do you grep > >> through log > >> > files for problems? Stop! Download the new AJAX search > >> engine that > >> > makes searching your log files as easy as surfing the web. > >> DOWNLOAD > >> > SPLUNK! > >> > > >> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121 > >> 6 > >> > 42 ___ > >> > hibernate-devel mailing list > >> > hibernate-devel@lists.sourceforge.net > >> > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > >> > >> > >> > >> -- > >> -- > >> Max Rydahl Andersen > >> callto://max.rydahl.andersen > >> > >> Hibernate > >> [EMAIL PROTECTED] > >> http://hibernate.org > >> > >> JBoss Inc > >> [EMAIL PROTECTED] > >> > >> > >> --- > >> This SF.net email is sponsored by: Splunk Inc. Do you grep through > >> log files for problems? Stop! Download the new AJAX > search engine > >> that makes searching your log files as easy as surfing the web. > >> DOWNLOAD SPLUNK! > >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&; > >> dat=121642 > >> ___ > >> hibernate-devel mailing list > >> hibernate-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/hibernate-devel > >> > > > > -- > -- > Max Rydahl Andersen > callto://max.rydahl.andersen > > Hibernate > [EMAIL PROTECTED] > http://hibernate.org > > JBoss Inc > [EMAIL PROTECTED] > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [Hibernate] Do antlr exception leak to users?
I'm a little concerned that this will lead to unnecessary coupling of client and server versions of antlr then. How often does an antlr exception as a cause show up in practise as an exception seen by an external client? > -Original Message- > From: Max Andersen > Sent: Monday, February 06, 2006 11:53 AM > To: Scott M Stark; jboss-development@lists.sourceforge.net; > Hibernate development > Subject: Re: [Hibernate] Do antlr exception leak to users? > > On Mon, 06 Feb 2006 20:49:08 +0100, Scott M Stark > <[EMAIL PROTECTED]> > wrote: > > > I'm seeing some incompatible serial version uid changes in > the latest > > antlr, but I don't know if antlr exceptions every leak to users > > outside of the vm such that this is an issue. Do the ql grammar > > exception get exposed or are they always converted to a > hibernate exception? > > it is always converted, but of course it can be inside as a > cause exception. > > /max --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [Hibernate] Do antlr exception leak to users?
The problem is the source of the cause not providing a stable api for
the exception, not the inclusion of the cause itself. The solution is to
fix the antlr exceptions to specify the serialVersionUID to avoid
trivial changes showing up as version incompatibilities.
You can always work around this by explicitly incorporating the cause
into the exception message string:
try
{
...
}
catch(Exception e)
{
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter();
pw.println("... cause:");
e.printStackTrace(pw);
pw.close();
String msg = sw.toString();
throw new Xception(msg);
}
> -Original Message-
> From: Max Andersen
> Sent: Tuesday, February 07, 2006 10:34 AM
> To: Scott M Stark; jboss-development@lists.sourceforge.net;
> Hibernate development
> Subject: Re: [Hibernate] Do antlr exception leak to users?
>
> On Tue, 07 Feb 2006 19:24:38 +0100, Scott M Stark
> <[EMAIL PROTECTED]>
> wrote:
>
> > I'm a little concerned that this will lead to unnecessary
> coupling of
> > client and server versions of antlr then. How often does an antlr
> > exception as a cause show up in practise as an exception seen by an
> > external client?
>
> hmm..whenever a syntax error occur in a HQL/EJBQL statement.
>
> But how else can we provide the cause of an exception ?
> This is a pretty critical part of debugging hibernate applications.
> Not just for antlr exceptions, but jdbc driver exceptions,
> sqlexceptions and any other external "cause".
>
> /max
>
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [Hibernate] Release naming conventions
I added a Practices and Jar Manifest Headers section to the JBossProductVersioning page to discuss issues such as how nightly builds could be versioned. The headers section still needs to be completed. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Scott M Stark > Sent: Tuesday, February 07, 2006 10:22 AM > To: Max Andersen; Christian Bauer; development Hibernate; > [EMAIL PROTECTED] > Cc: jboss-development@lists.sourceforge.net > Subject: RE: [Hibernate] Release naming conventions > > Any place the version is actually used. This is the manifest > headers (these should also be spelled out and standardized > including the osgi conventions for projects that need to > comply with these headers), the repository > component-info.xml, and the project build files. Really only > the project build file should be where a project makes > version changes and this should just propagated to artifacts > based on the build tools. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [Hibernate] Do antlr exception leak to users?
> fixing the antlr exception svuid won't help us if the client > is using an older version, right ? > It will if the serialVersionUID is set to the implicit value from the previous version. This can be done if the version is still serializable compatible. > calling printStackTrace() on every exception sounds overkill > for me...and will turn basic logging into something very verbose. > Should be no different from now as logging generally includes the cause. > I understand the issue, but don't find the suggested > solutions any good ;( > > Would be nice to have an option to have any exposed remote > exception do the serialization of the "cause". > Would make it a non-issue where it actually matters. > This can't be done without modifying the exception either via source or bytecode manipulation. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Accepted: [JBoss-dev] Maven2 discussion
BEGIN:VCALENDAR METHOD:REPLY PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:(GMT-06.00) Central Time (US & Canada) X-MICROSOFT-CDO-TZID:11 BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:-0500 TZOFFSETTO:-0600 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETFROM:-0600 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=4;BYDAY=1SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20060207T001658Z DTSTART;TZID="(GMT-06.00) Central Time (US & Canada)":20060208T09 SUMMARY:Accepted: [JBoss-dev] Maven2 discussion UID:04008200E00074C5B7101A82E008905F2284492BC601000 010007AD3E23387F0E54BBDA4311EDA6FC1FC ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE;CN="Scott M Stark ":MAILTO:[EMAIL PROTECTED] ORGANIZER:MAILTO:jboss-development@lists.sourceforge.net LOCATION:virtual DTEND;TZID="(GMT-06.00) Central Time (US & Canada)":20060208T10 SEQUENCE:0 PRIORITY:5 CLASS: CREATED:20060208T124445Z LAST-MODIFIED:20060208T124445Z STATUS:TENTATIVE TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-REPLYTIME:20060208T124243Z X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:889595862 END:VEVENT END:VCALENDAR
[JBoss-dev] RE: [Hibernate] Do antlr exception leak to users?
> which it isn't afaik. the antlr version started to include > more data in the exception over time. > Including additional data is not an incompatible serialzable change generally. Its optional data that will be ignored and cannot affect the legacy implementation. > >> calling printStackTrace() on every exception sounds overkill for > >> me...and will turn basic logging into something very verbose. > >> > > Should be no different from now as logging generally > includes the cause. > > well, for me that is showing the exception message in a > dialog in the ui I would be very disappointed to have a full > stack trace in the message output. > True, but this can be handled by wrapping the stacktrace in a generic exception whose msg is the cause stacktrace. > > And bytecode manipulation or simple modification of the > exception in the jboss serialization/remoting layer have that > option, correct ? Dealing with incorrect serialization implementation via hacks at the serialization layer is not a scalable solution. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [Hibernate] Do antlr exception leak to users?
Right. The issue is we can't have the infinite web of project implementation details leaking to users unncessarily. Hibernate is a little different in that its used both in Java SE and Java EE profiles. My concern is that a pure Java EE client should not care about that antlr happens to be used for the ejb3 query language parser. Antlr should not be a required jar in the jboss client jars for ejb3 usage. > -Original Message- > From: Steve Ebersole > Sent: Wednesday, February 08, 2006 6:52 AM > To: Max Andersen; Scott M Stark; > jboss-development@lists.sourceforge.net; Hibernate development > Subject: RE: [Hibernate] Do antlr exception leak to users? > > Well I think the distinction here is that Hibernate > constitutes a "hard" dependency on Antlr. The users choice > to use Oracle is completely within their control. > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] On the edge of the Maven cliff
So after listening to the Maven2 webinar yesterday and talking with Ryan, Ruel and Steve E as a lead, I don't see a good reason why we shouldn't look to using maven2 as the core of the jbossbuild. The two outstanding proof of concept issues I asked Ruel to look at are: 1. Source in the repository. A goal we have had is to be able to pull down the source for a dependent component as part of a depdency relationship. Maven2 has a weak notion of this but not one to the point of actually being able to build the component artifacts from the respository source. 2. Being able to create a plugin that does the equivalent of the org.jboss.ant.util.graph.ComponentRefGraphLicenseVisitor which generates the thirdparty-licenses.xml info. Once its clear these can be done I don't have a reason to not move jbossas to maven. If there are project leads that have not gone through the webinar and thought about how your project could use maven its time to do so. I'm still open to why maven should not be used, but given how Ruel has been able to interact well with the maven community and lack of progress on a custom jbossbuild, its going to be an uphill battle. Although we can hack the existing project structure into maven, switching seems like a good time to address inconsistencies in terms of project structure to allow for better definition of project structure such that unit tests, docs, and poorly maintained artifacts such as thirdparty licenses and notices are just handled by build plugins. Once we decide to jump off the maven2 cliff, defining this needs to be the priority so that projects can move as desired, and qa can do the work to move a project if needed. Scott Stark VP Architecture & Technology JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] On the edge of the Maven cliff
Great. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Burke > Sent: Thursday, February 09, 2006 7:54 AM > To: jboss-development@lists.sourceforge.net; Tim O'Brien > Subject: Re: [JBoss-dev] On the edge of the Maven cliff > > I've put a Maven contributor and evangelist in copy. Maybe > Tim can also facilitate us getting involved with the project > at Apache. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] On the edge of the Maven cliff
So this is item 3 on Ruel's list to look into. It's related to item 1. as I explained its usage to Ruel. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Adrian Brock > Sent: Thursday, February 09, 2006 8:14 AM > To: jboss-development@lists.sourceforge.net > Subject: Re: [JBoss-dev] On the edge of the Maven cliff > > The problem I don't see addressed (and the main reason why I > started the jbossbuild prototype) is to have a top level > which includes multiple projects. > > e.g. I wanted people to be able to do something like: > > > quality="LastGoodTests"> > > > > > This would checkout the last binaries for JBossAS that passed > the testsuite (except EJB3 which is latest source) and also Seam. > > You would then be able to build a Seam environment with just the > EJB3 and Seam sources. > > i.e. the developer only has to worry about the problems with > the stuff he is working on, rather than figuring out why > something unrelated doesn't compile/work. > > Instead, the jbossbuild project morphed into a mechanism to > download thirdparty binaries with buildmagic still used for > the main build. > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] On the edge of the Maven cliff
Yes, leveraging a community of people interested in builds vs jboss resources makes more sense. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Burke > Sent: Thursday, February 09, 2006 8:21 AM > To: jboss-development@lists.sourceforge.net > Subject: Re: [JBoss-dev] On the edge of the Maven cliff > > That would kick ass... > > Still, I think we should become Maven contributors and extend > Maven to do this. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] On the edge of theMaven cliff
I don't see stabilization happening though as we still have the pending maven move and restructing to have a common module structure and potentially splitting up existing projects to better match the maven ideal. Let's just define how we want commons broken up with Ruel in the loop so he can chase it. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Adrian Brock > Sent: Friday, February 10, 2006 2:47 AM > To: jboss-development@lists.sourceforge.net > Subject: Ongoing build changes: was RE: [JBoss-dev] On the > edge of theMaven cliff > > On a related issue. I really want to bite the bullet on > sorting out the jboss-common dependencies and making more > managable chuncks for standalone projects to eat. > > I've been waiting for the ongoing build changes to stabalise > before doing this in jboss-head. > > This would allow us to properly have one code base for things > like JBoss Logging, JBossXB, JBossAOP, JBossMC with 4.0.x and > 5.0.x consuming these projects based on their own versions > and branches rather than time consuming and potentially > unreliable backports. > > This would also fix the potential problems with JBoss Cache, > Remoting, Seam, etc. compiling over unknown versions of these > libraries copied at some point in the past from the JBossAS build. > > My question is how does this impact the work being done for > the Maven build? The last time I looked, only a minimal Maven > build was done which was essentially just building the > projects that I want to "fix" (fix as in make not broken Scott :-). > -- > > Adrian Brock > Chief Scientist > JBoss Inc. > > > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files for problems? Stop! Download the new AJAX > search engine that makes searching your log files as easy as > surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&; > dat=121642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] On the edge oftheMaven cliff
Part of the problem is everyone running around trying to get work done on multiple branches while Ruel is trying to baby step new build setups in. I think we need to get to a point where we just say head is going to be refactored and potentially broken for an extended period of time while we refactor it for: - build structure - module coarseness and invalid dependencies (like the server/security issue) - refactoring for integration api introduction The production branches have to remain stable during this. > -Original Message- > From: Adrian Brock > Sent: Friday, February 10, 2006 4:43 AM > To: jboss-development@lists.sourceforge.net > Cc: QA > Subject: RE: Ongoing build changes: was RE: [JBoss-dev] On > the edge oftheMaven cliff > > We already have a task for it > http://jira.jboss.com/jira/browse/JBBUILD-58 > > But I don't believe anybody has really looked at what it will > take in general. > > My comments on the issue in the forums are mainly based on > what I remember seeing when I was fixing other things. > > None of the JIRA tasks contain a link to these discussions. > Which is my fault. :-( > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] On the edgeoftheMaven cliff
I'm not following. aop and xb are no brainer standalone projects that should not be in the jbossas cvs module alias by default. ws and ejb3 probably need to be refactored into standalone modules and a server integration module which can be included in jbossas. I'm not advocating chaos in head because its a good thing. We just need to get to a point where getting this fixed is a priority, and be willing to live with some breakage to get there. If it needs a phased approach, that is fine. What do you suggest? > -Original Message- > From: Adrian Brock > Sent: Friday, February 10, 2006 5:15 AM > To: Scott M Stark > Cc: jboss-development@lists.sourceforge.net; QA > Subject: RE: Ongoing build changes: was RE: [JBoss-dev] On > the edgeoftheMaven cliff > > Ironically, one of the problems I am trying to solve will be > made worse by this approach. > > That is the number of projects that are really standalone but > are developed in head alongside the application server code. > e.g. AOP, JBossXB, JBossWS, EJB3 > > They need a useable head branch, even if nobody seems to be > paying too much attention to all the testsuite failures. > > I agree with that we shouldn't do anything to the production > branches until we have validated everything in head. > > On Fri, 2006-02-10 at 07:56, Scott M Stark wrote: > > Part of the problem is everyone running around trying to > get work done > > on multiple branches while Ruel is trying to baby step new build > > setups in. I think we need to get to a point where we just > say head is > > going to be refactored and potentially broken for an > extended period > > of time while we refactor it for: > > > > - build structure > > - module coarseness and invalid dependencies (like the > server/security > > issue) > > - refactoring for integration api introduction > > > > The production branches have to remain stable during this. > > > > > -Original Message- > > > From: Adrian Brock > > > Sent: Friday, February 10, 2006 4:43 AM > > > To: jboss-development@lists.sourceforge.net > > > Cc: QA > > > Subject: RE: Ongoing build changes: was RE: [JBoss-dev] > On the edge > > > oftheMaven cliff > > > > > > We already have a task for it > > > http://jira.jboss.com/jira/browse/JBBUILD-58 > > > > > > But I don't believe anybody has really looked at what it > will take > > > in general. > > > > > > My comments on the issue in the forums are mainly based on what I > > > remember seeing when I was fixing other things. > > > > > > None of the JIRA tasks contain a link to these discussions. > > > Which is my fault. :-( > > > > -- > > Adrian Brock > Chief Scientist > JBoss Inc. > > > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] On theedgeoftheMaven cliff
So we need to carve out a "minimal" impact strategy considering projects that today are tied to the jbossas head cvs structure. Maybe we need a nightly snapshot of jbossas in the repository with redefinition of projects like ejb3 to decouple them during the transition. > -Original Message- > From: Adrian Brock > Sent: Friday, February 10, 2006 6:46 AM > To: Scott M Stark > Cc: jboss-development@lists.sourceforge.net; QA > Subject: RE: Ongoing build changes: was RE: [JBoss-dev] On > theedgeoftheMaven cliff > > On Fri, 2006-02-10 at 08:39, Scott M Stark wrote: > > I'm not following. aop and xb are no brainer standalone > projects that > > should not be in the jbossas cvs module alias by default. > ws and ejb3 > > probably need to be refactored into standalone modules and a server > > integration module which can be included in jbossas. > > > > Yes, because WS and EJB3 use the same codebase to target > different JBossAS releases. Bill already has some > compatibility code to try to deal with this in EJB3. > > > I'm not advocating chaos in head because its a good thing. We just > > need to get to a point where getting this fixed is a > priority, and be > > willing to live with some breakage to get there. If it > needs a phased > > approach, that is fine. What do you suggest? > > > > I was advocating the same JFDI (Just *#&^ Do It) approach > with my "byte with bullet" comment. :-) > > I was just pointing out the potential problems it may cause > people in terms of current development during the transition. > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMaven cliff
Let's do that. Do you want to couple this to maven? It would help Ruel I suppose. > -Original Message- > From: Adrian Brock > Sent: Friday, February 10, 2006 9:34 AM > To: Scott M Stark > Cc: jboss-development@lists.sourceforge.net; QA > Subject: RE: Ongoing build changes: was RE: [JBoss-dev] > OntheedgeoftheMaven cliff > > On Fri, 2006-02-10 at 10:32, Scott M Stark wrote: > > So we need to carve out a "minimal" impact strategy considering > > projects that today are tied to the jbossas head cvs > structure. Maybe > > we need a nightly snapshot of jbossas in the repository with > > redefinition of projects like ejb3 to decouple them during > the transition. > > > > I could certainly create a branch where we could initially > measure the impact of the combined Maven/common changes. > > The main issue being the circularity dependencies across > common which aren't visible with everything in one project. > -- > > Adrian Brock > Chief Scientist > JBoss Inc. > > > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
That would be a way to actually start with a 4.0 branch fork which might be more manageable due to fewer changes to merge between the cvs and svn repositories. Can we get the jboss-4.0.x and jboss-head contents moved into svn Damon? -Original Message- From: Adrian Brock Sent: Saturday, February 11, 2006 3:48 AM To: Scott M Stark Cc: jboss-development@lists.sourceforge.net; QA Subject: RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff On Sat, 2006-02-11 at 04:33, Adrian Brock wrote: > On Fri, 2006-02-10 at 13:28, Scott M Stark wrote: > > Let's do that. Do you want to couple this to maven? It would help Ruel I > > suppose. > > We may as well go "Big Bang!". :-) Speaking of Big Bang. It might be idea to convert to subversion at the same time. Given we want to refactor the project structures to native Maven we could: 1) Import CVS into SVN 2) Use SVN rename to rework the project structure 3) Keep the history attached to those files! http://weblogs.java.net/blog/joshy/archive/2005/03/subversion_rena.html -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
4.0 vs head is a tradeoff of how long its going to take and how this relates to how much has to be merged to the ultimate svn structure. What are you referring to in terms of increased time, the download from the repository, maven, both? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Oliver Sent: Saturday, February 11, 2006 12:47 PM To: jboss-development@lists.sourceforge.net Subject: Re: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff gosh wouldn't it make more sense to do all of this for 5.0 where there is a free hand rather than 4.0? Do we have feasibility targets (i.e. the build cannot suddenly take 5 hours on a IA64 with 8 gb of ram) for this? -andy (who finds maven and all things like it to be really frustrating) Damon Sicore wrote: > Adding them now... ;-) > > On Feb 11, 2006, at 2:38 PM, Scott M Stark wrote: > >> That would be a way to actually start with a 4.0 branch fork which might >> be more manageable due to fewer changes to merge between the cvs and svn >> repositories. >> >> Can we get the jboss-4.0.x and jboss-head contents moved into svn Damon? >> >> -Original Message- >> From: Adrian Brock >> Sent: Saturday, February 11, 2006 3:48 AM >> To: Scott M Stark >> Cc: jboss-development@lists.sourceforge.net; QA >> Subject: RE: Ongoing build changes: was RE: [JBoss-dev] >> OntheedgeoftheMavencliff >> >> On Sat, 2006-02-11 at 04:33, Adrian Brock wrote: >> >>> On Fri, 2006-02-10 at 13:28, Scott M Stark wrote: >>> >>>> Let's do that. Do you want to couple this to maven? It would help >> >> Ruel I >> >>>> suppose. >>> >>> >>> We may as well go "Big Bang!". :-) >> >> >> Speaking of Big Bang. It might be idea to convert to subversion at the >> same time. >> Given we want to refactor the project structures to native Maven >> we could: >> >> 1) Import CVS into SVN >> 2) Use SVN rename to rework the project structure >> 3) Keep the history attached to those files! >> >> http://weblogs.java.net/blog/joshy/archive/2005/03/ subversion_rena.html >> -- >> >> Adrian Brock >> Chief Scientist >> JBoss Inc. >> >> >> >> >> --- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through >> log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 >> ___ >> JBoss-Development mailing list >> JBoss-Development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
Tim is suggesting that if we plan on moving modules around, Subversion's svn:externals facility might be something we want to examine as a mechanism for relating components (and different versions of those components) to large "deliverables". You end up storing each distinct component in a normal "trunk", "tags", "branches" directory that subversion users are used to, and you aggregate components into larger releases using the svn:externals property on a directory. He found this method to be helpful becuase it allows you to create releases of independently versioned subcomponents. Maven uses it here: http://svn.apache.org/repos/asf/maven/trunks/ Jakarta Commons uses it here: http://svn.apache.org/repos/asf/jakarta/commons/trunks-proper/ -Original Message- From: Adrian Brock Sent: Saturday, February 11, 2006 3:48 AM To: Scott M Stark Cc: jboss-development@lists.sourceforge.net; QA Subject: RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff On Sat, 2006-02-11 at 04:33, Adrian Brock wrote: > On Fri, 2006-02-10 at 13:28, Scott M Stark wrote: > > Let's do that. Do you want to couple this to maven? It would help Ruel I > > suppose. > > We may as well go "Big Bang!". :-) Speaking of Big Bang. It might be idea to convert to subversion at the same time. Given we want to refactor the project structures to native Maven we could: 1) Import CVS into SVN 2) Use SVN rename to rework the project structure 3) Keep the history attached to those files! http://weblogs.java.net/blog/joshy/archive/2005/03/subversion_rena.html -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
The committer lists needs to be everyone currently doing work on jbossas which is pretty large. Take whoever has made a commit in the past 6 months as a start. -Original Message- From: Damon Sicore Sent: Saturday, February 11, 2006 1:14 PM To: jboss-development@lists.sourceforge.net Cc: Adrian Brock; QA; Tom Benninger; Eric Brown Subject: Re: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff OK... Seriously... It will take me about 15 mins to do the import, but more importantly, I'll need to get the list of committers added to the proper branch structures in svn. This will take me a bit of time to do first, but, I'll start now. After they are added, you can easily coordinate people using the new repo at your leisure. Do you have a list of committers, and only those committers, you want for these branches? Is there a subset of all the committers? Since we have directory level access controls, we can do this, and I recommend it. Also, I'd recommend making the switch.. officially... after Eric and TomBen get the anonsvn off the fisheye, committer, cvs, and [insert- every-other-app-here] machine. It's currently running at a load of 10 on a single proc machine (or something close). Eric? On Feb 11, 2006, at 2:38 PM, Scott M Stark wrote: --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
The svn repos are just copies, they are not where development will be done until this is validated. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Adrian Brock > Sent: Sunday, February 12, 2006 1:36 AM > To: jboss-development@lists.sourceforge.net > Subject: [JBoss-dev] RE: Ongoing build changes: was RE: > [JBoss-dev] OntheedgeoftheMavencliff > > I thought the plan was to validate first? > > We can't just make a switch to SVN at 5 minutes notice on a > few peoples' say so. > > People need to confirm they can switch to the new tools and > have time to adapt. e.g. > > * they already have unchecked in work against cvs > * they need to download and understand the tools > * they need to find and discuss problems > > I used SVN for the first time only yesterday. :-) > > I found checking out from SVN and performing the maven build > very slow compared to what we have now. > Admittedly it will be faster now I have a populated local repository. > > I still don't know how to make this compile within Eclipse? > i.e. > Without a standard location for thirdparty how do we share > the Eclipse project descriptors? > Although, I believe Maven has a task to generate them locally > rather than sharing them, I don't currently know how to do this. > > On Sat, 2006-02-11 at 16:03, Scott M Stark wrote: > > 4.0 vs head is a tradeoff of how long its going to take and > how this > > relates to how much has to be merged to the ultimate svn structure. > > > > What are you referring to in terms of increased time, the download > > from the repository, maven, both? > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Andrew Oliver > > Sent: Saturday, February 11, 2006 12:47 PM > > To: jboss-development@lists.sourceforge.net > > Subject: Re: Ongoing build changes: was RE: [JBoss-dev] > > OntheedgeoftheMavencliff > > > > gosh wouldn't it make more sense to do all of this for 5.0 > where there > > is a free hand rather than 4.0? > > > > Do we have feasibility targets (i.e. the build cannot > suddenly take 5 > > hours on a IA64 with 8 gb of ram) for this? > > > > -andy (who finds maven and all things like it to be really > > frustrating) > > > > Damon Sicore wrote: > > > Adding them now... ;-) > > > > > > On Feb 11, 2006, at 2:38 PM, Scott M Stark wrote: > > > > > >> That would be a way to actually start with a 4.0 branch > fork which > > might > > >> be more manageable due to fewer changes to merge between > the cvs > > >> and > > svn > > >> repositories. > > >> > > >> Can we get the jboss-4.0.x and jboss-head contents moved into svn > > Damon? > > >> > > >> -Original Message- > > >> From: Adrian Brock > > >> Sent: Saturday, February 11, 2006 3:48 AM > > >> To: Scott M Stark > > >> Cc: jboss-development@lists.sourceforge.net; QA > > >> Subject: RE: Ongoing build changes: was RE: [JBoss-dev] > > >> OntheedgeoftheMavencliff > > >> > > >> On Sat, 2006-02-11 at 04:33, Adrian Brock wrote: > > >> > > >>> On Fri, 2006-02-10 at 13:28, Scott M Stark wrote: > > >>> > > >>>> Let's do that. Do you want to couple this to maven? It > would help > > >> > > >> Ruel I > > >> > > >>>> suppose. > > >>> > > >>> > > >>> We may as well go "Big Bang!". :-) > > >> > > >> > > >> Speaking of Big Bang. It might be idea to convert to > subversion at > > the > > >> same time. > > >> Given we want to refactor the project structures to > native Maven we > > >> could: > > >> > > >> 1) Import CVS into SVN > > >> 2) Use SVN rename to rework the project structure > > >> 3) Keep the history attached to those files! > > >> > > >> http://weblogs.java.net/blog/joshy/archive/2005/03/ > > subversion_rena.html > > >> -- > > >> > > >> Adrian Brock > > >> Chief Scientist > > >> JBoss Inc. > > >> > > >> > > >> > > >> > > >> --
RE: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
I have validated ecliplse, intellij(which did require permission changes on our end to work), and cygwin command line svn tools. My mind still has not switched from the cvs tag/branch conventions and so the history/log are not very intuitive yet. I need more info in the following forum posting to understand how this should work: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76175 This references the following branch policy draft: http://labs.jboss.com/wiki/BranchingPolicy > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Adrian Brock > Sent: Sunday, February 12, 2006 1:36 AM > To: jboss-development@lists.sourceforge.net > Subject: [JBoss-dev] RE: Ongoing build changes: was RE: > [JBoss-dev] OntheedgeoftheMavencliff > > I thought the plan was to validate first? > > We can't just make a switch to SVN at 5 minutes notice on a > few peoples' say so. > > People need to confirm they can switch to the new tools and > have time to adapt. e.g. > > * they already have unchecked in work against cvs > * they need to download and understand the tools > * they need to find and discuss problems > > I used SVN for the first time only yesterday. :-) > > I found checking out from SVN and performing the maven build > very slow compared to what we have now. > Admittedly it will be faster now I have a populated local repository. > > I still don't know how to make this compile within Eclipse? > i.e. > Without a standard location for thirdparty how do we share > the Eclipse project descriptors? > Although, I believe Maven has a task to generate them locally > rather than sharing them, I don't currently know how to do this. > > On Sat, 2006-02-11 at 16:03, Scott M Stark wrote: > > 4.0 vs head is a tradeoff of how long its going to take and > how this > > relates to how much has to be merged to the ultimate svn structure. > > > > What are you referring to in terms of increased time, the download > > from the repository, maven, both? > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Andrew Oliver > > Sent: Saturday, February 11, 2006 12:47 PM > > To: jboss-development@lists.sourceforge.net > > Subject: Re: Ongoing build changes: was RE: [JBoss-dev] > > OntheedgeoftheMavencliff > > > > gosh wouldn't it make more sense to do all of this for 5.0 > where there > > is a free hand rather than 4.0? > > > > Do we have feasibility targets (i.e. the build cannot > suddenly take 5 > > hours on a IA64 with 8 gb of ram) for this? > > > > -andy (who finds maven and all things like it to be really > > frustrating) > > > > Damon Sicore wrote: > > > Adding them now... ;-) > > > > > > On Feb 11, 2006, at 2:38 PM, Scott M Stark wrote: > > > > > >> That would be a way to actually start with a 4.0 branch > fork which > > might > > >> be more manageable due to fewer changes to merge between > the cvs > > >> and > > svn > > >> repositories. > > >> > > >> Can we get the jboss-4.0.x and jboss-head contents moved into svn > > Damon? > > >> > > >> -Original Message- > > >> From: Adrian Brock > > >> Sent: Saturday, February 11, 2006 3:48 AM > > >> To: Scott M Stark > > >> Cc: jboss-development@lists.sourceforge.net; QA > > >> Subject: RE: Ongoing build changes: was RE: [JBoss-dev] > > >> OntheedgeoftheMavencliff > > >> > > >> On Sat, 2006-02-11 at 04:33, Adrian Brock wrote: > > >> > > >>> On Fri, 2006-02-10 at 13:28, Scott M Stark wrote: > > >>> > > >>>> Let's do that. Do you want to couple this to maven? It > would help > > >> > > >> Ruel I > > >> > > >>>> suppose. > > >>> > > >>> > > >>> We may as well go "Big Bang!". :-) > > >> > > >> > > >> Speaking of Big Bang. It might be idea to convert to > subversion at > > the > > >> same time. > > >> Given we want to refactor the project structures to > native Maven we > > >> could: > > >> > > >> 1) Import CVS into SVN > > >> 2) Use SVN rename to rework the project structure > > >> 3) Keep the history attached to those files!
RE: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
Its not true that the entire cvs repository is tagged when a release is done. There are numerous cvs module aliases encompassing different release components. In a large aggregation of components such occurs in jbossas, the jbossas cvs module alias is tagged, and many components come in as binaries based on the version referenced in the jbossas thirdparty build declarations. That behavior mirrors the maven behavior. There is no clean mapping from the version reference to the cvs/svn source tree that that corresponds to the binary. This is due to different version conventions, and repositories. The version convention has been unified and now we need a unified svn convention. This really is consistent with putting the types of branches under the project root url. How this works with tools is whay I wanted to see how one performs various tasks on a project from the command line and ide svn tools. We don't have a usecase for obtaining all trunks, qa, etc. so it would be a question for Damon as to why he suggested this convention. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim OBrien Sent: Sunday, February 12, 2006 11:57 AM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff I read the SVN branching doc on the wiki, and here is some feedback. Instead of putting branches tags directories at the repository level where "/prod", "/qa", and "/trunk" encompass everything in the SVn repository. Create "trunk", "tags", and "branches" at the subproject level. Version each subproject in a /projects subdirectory and aggregate projects using svn:externals. It's convenient to keep all of the tags and branches of a specific component in a consolidated directory as I'm almost certain that there are SVN tools in development which will expect the familiar trunk, tags, branches convention. Thinking of a branch or a tag as something that happens to an entire repository is in keeping with the way JBoss performs releases in CVS. From what I heard last year, when JBoss cuts a release or tags, someone has to tag (or branch tag) the entire JBoss CVS repository. The drawback to repository-wide branching and tagging is that it prevents different subcomponents from releasing at different rates. Hibernate, jboss-mail, jboss-media, jboss-aop...all of these components may have different release rates. From the wiki document, it looks like every project that follows the three-tiered release model would have a directory in /trunk, /qa, and /prod. I'm assuming that the idea of putting /trunk, /qa, and /prod is one of convenience? This way someone only has to check out /trunk to get all trunks? If that's the motivation, then you could handle this case by using svn:externals and preserve the convention of "trunk", "tags", and "branches". Put trunk, "tags", and "branches" at the second level (keep the names as certian toolsets will start relying on this convention). Resources on trunks, tags, branches: "Subversion Book" - http://svnbook.red-bean.com/en/1.1/ch05s04.html "How Fisheye works with Trunks, Tags, Branches" - http://www.cenqua.com/fisheye/doc/1.1/admin/svnsymbolic.html Note: I'd suggest either the second-level approach or a custom layout. Other projects have had similar discussions: http://lists.gnu.org/archive/html/gnustep-dev/2005-10/msg00057.html http://pkg-perl.alioth.debian.org/subversion.html --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Maven build and scripting was Re: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
We are mixing several issues here though. 1. Ruel's attempt to replicate the build using maven was a question as to whether maven could handle a screwed up build structure. 2. Since this is not ideal and maven has an even stricter notion of a source tree/per artificat, should the build be restructured to more closely mirror this notion to remove the hacks Ruel used. 3. There are additional changes being discussed with regard to breaking up existing cvs modules and artifacts (common -> jboss-common.jar) to separate out projects like jbossxb which should be evolvoing indepedently of the app server. 4. svn blah blah. The point I take from Adrian is that if we have to do something beyond what maven supports via an existing plugin, it needs to be encapsulated in a custom plugin. It cannot be ad hoc scripting in the build descriptors. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Ruel Loehr > Sent: Monday, February 13, 2006 8:44 AM > To: jboss-development@lists.sourceforge.net > Subject: RE: Maven build and scripting was Re: [JBoss-dev] > RE: Ongoing build changes: was RE: [JBoss-dev] > OntheedgeoftheMavencliff > > In our current configuration, the jar plugin is not adequate. > For a given module, we need to build many artifacts (see the > build forum post > here): > > http://www.jboss.com/index.html?module=bb&op=viewtopic&p=39233 > 33#392 > > I spent some time looking at the assembly plugin as well, but > did not find it suitable for the following reasons. > > 1) It must be called manually. We don't want to have to > call this for > each module. > 2) It lacks functionality for adding classes from > dependencies into a jar. E.g, I want to create a jar and add > some classes from another modules output. > 3) It seemed to me overall that the assembly plugin was best > used for creating the final project structure, not for > building the outputs of each subproject. > > If I am wrong, please correct me. > > Ruel Loehr > JBoss QA --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] So does svn really work in the ides?
So I tried using this tomcat svn repo in both eclipse using the http://subclipse.tigris.org/ plugin and in intellij 5.1. http://svn.apache.org/repos/asf/tomcat/current/tc5.5.x I found a line referring to the "people wearing tin hats" in one of the tomcat files and wanted to see who the commedian was, but the annotate command in intellij did nothing. The history view just showed a huge list of number that could not be arranged into any type of structure and I got tired of browsing through the comments to find the change. Using eclipse I could not even checkout the tc5.5.x project using the Import->Checkout from SVN command. When it got to the "Select the folder to be checked out from SVN" dialog, it was just blank. So far I'm underwhelmed with the svn tool support. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] So does svn really work in the ides?
The checkout works fine from the command line. So I need a feature request to have subeclipse follow the svn:externals reference it would seem. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Tim OBrien > Sent: Tuesday, February 14, 2006 10:30 PM > To: jboss-development@lists.sourceforge.net > Subject: Re: [JBoss-dev] So does svn really work in the ides? > > Scott, > > see below, Subclipse is working just fine. > > --- Scott M Stark <[EMAIL PROTECTED]> wrote: > > > > Using eclipse I could not even checkout the tc5.5.x project > using the > > Import->Checkout from SVN command. When it got to the "Select the > > Import->folder > > to be checked out from SVN" dialog, it was just blank. > > That's because the directory you were trying to browse is > empty. It contains svn:externals references. Try > http://svn.apache.org/repos/asf/tomcat/current/ or better yet > try http://svn.apache.org/repos/asf > > Run "svn propget svn:externals" on the directory you were > trying to checkout to see this externals property. Once > y'all grok svn:externals, I think you'll be able to use it to > your advantage. > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files for problems? Stop! Download the new AJAX > search engine that makes searching your log files as easy as > surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&; > dat=121642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] client libraries on EJB3
Huh? We are propagating relationships across jvm boundaries? That does not make sense. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Clebert Suconic > Sent: Wednesday, February 15, 2006 1:22 PM > To: jboss-development@lists.sourceforge.net > Subject: RE: [JBoss-dev] client libraries on EJB3 > > IMO we need to add the whole asm, cglib and hibernate.proxy > into hibernate3-client. > These packages are required on any lazy relationship. > > > Clebert --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] client libraries on EJB3
Title: Re: [JBoss-dev] client libraries on EJB3 Can this enhanced proxy be replaced during serialization to avoid this? If these classes cannot be used in a functional manner by a client, they should not be exposed to the client. Just replace the proxy with a wrapper around the lazy load exception. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert SuconicSent: Wednesday, February 15, 2006 4:31 PMTo: jboss-development@lists.sourceforge.net; jboss-development@lists.sourceforge.netSubject: RE: [JBoss-dev] client libraries on EJB3 we are not propagating relationships across JVM boundaries. But if you have a lazy relationship, you need CGLIB and ASM on the client side. So, if you don't have CGLib, ASM and Hibernate and using a lazy relationship you will get a ClassNotFoundException when deserializing the POJO on the client side. My point was should we add these libraries to /client, or should we add the classes to hibernate-client.jar? From: [EMAIL PROTECTED] on behalf of Bill BurkeSent: Wed 2/15/2006 5:34 PMTo: jboss-development@lists.sourceforge.netSubject: Re: [JBoss-dev] client libraries on EJB3 Unloaded relationships throw a lazy-loaded exception if accessed afterthe entity is detached.Scott M Stark wrote:> Huh? We are propagating relationships across jvm boundaries? That does> not make sense.-Original Message->>From: [EMAIL PROTECTED]>>[mailto:[EMAIL PROTECTED]] On>>Behalf Of Clebert Suconic>>Sent: Wednesday, February 15, 2006 1:22 PM>>To: jboss-development@lists.sourceforge.net>>Subject: RE: [JBoss-dev] client libraries on EJB3IMO we need to add the whole asm, cglib and hibernate.proxy>>into hibernate3-client.>>These packages are required on any lazy relationship.>>Clebert ---> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files> for problems? Stop! Download the new AJAX search engine that makes> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!> http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642> ___> JBoss-Development mailing list> JBoss-Development@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/jboss-development>--Bill BurkeChief ArchitectJBoss Inc.---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems? Stop! Download the new AJAX search engine that makessearching your log files as easy as surfing the web. DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642___JBoss-Development mailing listJBoss-Development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] client libraries on EJB3
Title: Re: [JBoss-dev] client libraries on EJB3 I'm asking if we can replace the proxy with one that throws the lazy loading exception on any method access without leaking dependencies on the proxy related classes. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert SuconicSent: Wednesday, February 15, 2006 5:16 PMTo: jboss-development@lists.sourceforge.net; jboss-development@lists.sourceforge.netSubject: RE: [JBoss-dev] client libraries on EJB3 Well... I'm not sure what would happen if the lazy relationship is filled. I guess you would get the ClassNotFoundException on any Lazy Relationship if hibernate.proxy is not availble. Bill? Kabir? I only tested without activating a Lazy Relationships.
RE: [JBoss-dev] client libraries on EJB3
Title: Re: [JBoss-dev] client libraries on EJB3 For the remote proxies and associated aspects yes, but I don't want proxy stuff leaking for no good reason. A proxy that can only be used to cause an exception to be thrown is not a good reason to introduce a new library dependency on the client. If this was already javassist I would not have a problem since we likely want an aop container on the client. Leaking asm/cglib is not something I want to have to do. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert SuconicSent: Wednesday, February 15, 2006 5:41 PMTo: jboss-development@lists.sourceforge.net; jboss-development@lists.sourceforge.netSubject: RE: [JBoss-dev] client libraries on EJB3 we will need a proxy framework anyways, right? if we replace cglib by something else (aop, javassist maybe) I guess it would be the same on that point, and besides it would require some work.
RE: [JBoss-dev] client libraries on EJB3
But here we are talking about what exists after the object in question has been serialized outside of the jvm. Does what your talking about still apply in that situation? Regardless, I think this discussion just further pushes for a unified javassist based proxy framework sometime before ejb3 is finalized. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Max Rydahl Andersen > Sent: Wednesday, February 15, 2006 11:56 PM > To: jboss-development@lists.sourceforge.net > Cc: Steve Ebersole > Subject: Re: [JBoss-dev] client libraries on EJB3 > > Hi guys, > > Just bumping in here to tell the "whole" story about the > needed dependencies. > > Here are the reasons for ever neededing any hibernate > specific stuff on a "client" side: > > 1. Managing persistent collections > To track how a collection mutates so when the object > comes back to the server > hibernate can be more efficient when detecting and > executing changes. > > 2. Handle lazy loaded objects > If lazy="true" on a class (it is by default) the object > can be a simple proxied > shell only containing the id. This allows us to use the > object in associations > without loading it (e.g. child.setParent(proxiedParent);) > and to throw an exception > if it is accessed without being previously loaded or in a > session (e.g. > proxiedParent.getName() goes boom) > > #1 does not require proxy libraries AFAIK but I have not tested it. > > #2 requires the proxy libraries (in 3.2 either javaassist or > cglib), I don't know if it is feasible > to generate something that is not dependent on the proxy > library and still be able to reassociate it > when it comes back to the server. > > These are important issues that should be handled in > Hibernate 3.2 if at all possible. (cc'ed steve) > > /max --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] An ESB bomb just went off
If your not subscribed to the [EMAIL PROTECTED] (see how to subscribe here http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossDeveloperChannels) then you missed the explosion of JBossESB threads Mark Little has started. See the following forum for the threads: http://www.jboss.com/index.html?module=bb&op=viewforum&f=220 Scott Stark VP Architecture & Technology JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] client libraries on EJB3
So I guess we need a discussion on aop proxies in general such that when hibernate is combined with jboss ejb3/remoting/aop we know what the behavior is and how it relates to any aop configuration that might exist in the deserialization context. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Steve Ebersole > Sent: Thursday, February 16, 2006 10:10 AM > To: jboss-development@lists.sourceforge.net > Subject: RE: [JBoss-dev] client libraries on EJB3 > > Well unfortunately serialization is used in two distinct > scenarios that have vastly different de-serialization needs. > The current code is written to handle both scenarios. > > The first scenario is serialization of the Hibernate Session > itself such that when that Session is then de-serialized all > the proxies are properly re-attached and usable. > > The other scenario is serialization specifically to send > across a class-loader boundary. Theoretically we could just > replace the proxy with some "stand-in" object that just > always throws a LazyInitializationException. But "this > thing" still needs to be typed correctly upon > de-serialization in order to fulfill this role, so not sure > how to do that without the library being used for lazy proxy > generation being available on the client-side anyway. > > Hibernate 3.2 does have the ability to use Javassist as the > bytecode library instead of CGLIB. Hibernate 3.2 is the > version I am expecting to be used in EJB3 moving forward, so > there is no problem if you are fine with requiring Javassist > on the client-side... > > BTW, even with collections there is a possibility to still > need access to the proxy generation library on > de-serialization. This is because it is *possible* to have a > collection containing proxies in the case of many-to-many > associations. > > -Original Message- > From: Scott M Stark > Sent: Thursday, February 16, 2006 2:08 AM > To: jboss-development@lists.sourceforge.net > Cc: Steve Ebersole > Subject: RE: [JBoss-dev] client libraries on EJB3 > > But here we are talking about what exists after the object in > question has been serialized outside of the jvm. Does what > your talking about still apply in that situation? Regardless, > I think this discussion just further pushes for a unified > javassist based proxy framework sometime before ejb3 is finalized. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Max Rydahl Andersen > > Sent: Wednesday, February 15, 2006 11:56 PM > > To: jboss-development@lists.sourceforge.net > > Cc: Steve Ebersole > > Subject: Re: [JBoss-dev] client libraries on EJB3 > > > > Hi guys, > > > > Just bumping in here to tell the "whole" story about the needed > > dependencies. > > > > Here are the reasons for ever neededing any hibernate > specific stuff > > on a "client" side: > > > > 1. Managing persistent collections > > To track how a collection mutates so when the object > comes back to > > the server > > hibernate can be more efficient when detecting and executing > > changes. > > > > 2. Handle lazy loaded objects > > If lazy="true" on a class (it is by default) the object > can be a > > simple proxied > > shell only containing the id. This allows us to use the > object in > > associations > > without loading it (e.g. > child.setParent(proxiedParent);) and to > > throw an exception > > if it is accessed without being previously loaded or in > a session > > (e.g. > > proxiedParent.getName() goes boom) > > > > #1 does not require proxy libraries AFAIK but I have not tested it. > > > > #2 requires the proxy libraries (in 3.2 either javaassist > or cglib), I > > don't know if it is feasible > > to generate something that is not dependent on the > proxy library > > and still be able to reassociate it > > when it comes back to the server. > > > > These are important issues that should be handled in > Hibernate 3.2 if > > at all possible. (cc'ed steve) > > > > /max > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files for problems? Stop! Download the new AJAX > search engine that makes searching your log files as easy as > surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=k&kid3432&
[JBoss-dev] Long standing JMS Message Inflow testing
These two issues currently assigned to Tim: http://jira.jboss.com/jira/browse/JBAS-1434 http://jira.jboss.com/jira/browse/JBMESSAGING-170 have been waiting for quite a while. Are we going to be able to get these resolved for the 4.0.4.GA release due out in a month? Scott Stark VP Architecture & Technology JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Big backlog of cmp2 issues
So in going through the outstanding jira issues for jbas, there are a lot of old cmp2 issues. We have never really made a decision on whether we are going to try to move the cmp2 model onto an ejb3/hibernate based implementation. That would seem to be the best migration and support strategy. Scott Stark VP Architecture & Technology JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: 3.2.8 Client -> 4.0.x Compatibility
My suggestion is that the useFullHashMode be updated to include the hash
of all methods in there interface inheritence tree hashed to the
subinterfaces as well as the interface. So, an interface B like:
interface A
{
void m1(String);
}
interface B extends A
{
void m2(String);
}
would have a hash map of:
H(A:m1(String))
H(B:m1(String))
H(B:m2(String))
This solves the existing RMIAdaptor problem where some methods were
pushed into a superinterface. The extra method hashes don't hurt
anything.
> -Original Message-
> From: Clebert Suconic
> Sent: Friday, February 17, 2006 3:08 PM
> To: Scott M Stark; Ryan Campbell; Dimitris Andreadis
> Cc: jboss-development@lists.sourceforge.net; QA
> Subject: RE: 3.2.8 Client -> 4.0.x Compatibility
>
> I spent some time today with this issue. I just want to throw
> some ideas to fix this.
>
>
> First option:
>
> If you have 4.0:MarshalledInvocation.useFullHashMode=false,
> and 3.2:MarshalledInvocation.useFullHashMode=false, the
> testsuite should pass.
>
> So, we could change FullHashMode to false if some parameter
> is avaible, and 3.2.8.sp1 would be compatible with 4.0.4, but
> not 3.2.8. The easiest way would be have a parameter to
> change the FullHashMode on 4.0
>
>
>
> Second option:
>
> We could also have an interface on RMIAdaptorImpl and change
> MarshalledInvocation to do something like:
>
> public static Map getInterfaceHashes(Class intf)
> {
> If (intf ThatInterface)
> {
> ThatINterface that = (ThatInterface)intf.newInstance();
> ... delegate the hashCalculation to that, somehow.
> }
> }
>
>
> I don't like this idea, but I just wanted to throw something
> on the discussion, as a brain storm.
>
>
>
> Third options:
>
> An option also, would be to back port RMIAdaptor from 4.0.x
> to 3.2.8, but that would break compatibility between 3.2.8
> and previous versions, and I don't know if there is a way to
> have a selective classLoading between a newer and an older version.
>
>
>
>
> Any other idea/option?
> Thoughts?
>
>
> Clebert Suconic
>
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: 3.2.8 Client -> 4.0.x Compatibility
Title: RE: 3.2.8 Client -> 4.0.x Compatibility
Ok, so we would have:
4.0.x:
MBeanServerConnection:*
RMIAdaptor:add/removeNotificationListener(...)
3.2.8-:
RMIAdaptor:*
3.2.8.SP1:
RMIAdaptor:*
MBeanServerConnection:*
The real problem is not having the hash
codes, its choosing the right hash codes for the target server. You really need
to be able to build the hash map based on the connection.
From: Clebert Suconic
Sent: Friday, February 17, 2006
10:51 PM
To: Scott M Stark; Ryan Campbell; Dimitris Andreadis
Cc: 'jboss-development@lists.sourceforge.net';
QA
Subject: RE: 3.2.8 Client ->
4.0.x Compatibility
For doing that, you would need to implement that on [EMAIL PROTECTED],
what would make only possible a communication between 3.2.8.sp1 and 4.0.4.
If we had a way to inject other hashCodes on 3.2.8.sp1, we
would be able to have 3.2.8.sp1 communicating with previous versions of 4.0.4.
But I don't know if that is required.
Clebert
From: Scott M
Stark
Sent: Fri 2/17/2006 7:00 PM
To: Clebert Suconic; Ryan Campbell; Dimitris Andreadis
Cc: 'jboss-development@lists.sourceforge.net';
QA
Subject: RE: 3.2.8 Client ->
4.0.x Compatibility
My
suggestion is that the useFullHashMode be updated to include the hash of all
methods in there interface inheritence tree hashed to the subinterfaces as well
as the interface. So, an interface B like:
interface A
{
void m1(String);
}
interface B extends A
{
void m2(String);
}
would have a hash map of:
H(A:m1(String))
H(B:m1(String))
H(B:m2(String))
This solves the existing RMIAdaptor problem where some methods were pushed into
a superinterface. The extra method hashes don't hurt anything.
> -Original Message-
> From: Clebert Suconic
> Sent: Friday, February 17, 2006 3:08 PM
> To: Scott M Stark; Ryan Campbell;
Dimitris Andreadis
> Cc: jboss-development@lists.sourceforge.net;
QA
> Subject: RE: 3.2.8 Client -> 4.0.x Compatibility
>
> I spent some time today with this issue. I just want to throw
> some ideas to fix this.
>
>
> First option:
>
> If you have 4.0:MarshalledInvocation.useFullHashMode=false,
> and 3.2:MarshalledInvocation.useFullHashMode=false, the
> testsuite should pass.
>
> So, we could change FullHashMode to false if some parameter
> is avaible, and 3.2.8.sp1 would be compatible with 4.0.4, but
> not 3.2.8. The easiest way would be have a parameter to
> change the FullHashMode on 4.0
>
>
>
> Second option:
>
> We could also have an interface on RMIAdaptorImpl and change
> MarshalledInvocation to do something like:
>
> public static Map getInterfaceHashes(Class intf)
> {
> If (intf
ThatInterface)
> {
> ThatINterface that =
(ThatInterface)intf.newInstance();
> …
delegate the hashCalculation to that, somehow.
> }
> }
>
>
> I don't like this idea, but I just wanted to throw something
> on the discussion, as a brain storm.
>
>
>
> Third options:
>
> An option also, would be to back port RMIAdaptor from 4.0.x
> to 3.2.8, but that would break compatibility between 3.2.8
> and previous versions, and I don't know if there is a way to
> have a selective classLoading between a newer and an older version.
>
>
>
>
> Any other idea/option?
> Thoughts?
>
>
> Clebert Suconic
>
RE: [JBoss-dev] Long standing JMS Message Inflow testing
The ejb3 integration issues is something I will be looking at immeadiately after the 4.0.4.GA release. The 4.0.5.GA target is just when this has to be done by. Progress towards this will be showing up in 4.0.5.CR1. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Adrian Brock > Sent: Saturday, February 18, 2006 3:06 AM > To: jboss-development@lists.sourceforge.net > Subject: Re: [JBoss-dev] Long standing JMS Message Inflow testing > ... > > I'd prefer to find the time to write these tests myself then > we can move the JMSContainerInvoker with its practically > unoverridable implementation to legacy. > > This would also be one less thing to worry about for EJB3 > integration. Which I see you also moved to 4.0.5. > > In my opionion this is a mistake. If you keep pushing these > things back, people just learn to ignore it knowing that if > they leave it long it enough it will be keep getting deferred > to the next release. > > e.g. The "critical" clustering issue that has been hanging > around for months: > http://jira.jboss.com/jira/browse/JBAS-1476 > I hope this isn't going to get pushed back as well. > > These critical issues should really be done in the next > availble release candidate, not done at the last minute for > the GA release. > -- > > Adrian Brock > Chief Scientist > JBoss Inc. > > > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files for problems? Stop! Download the new AJAX > search engine that makes searching your log files as easy as > surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&; > dat=121642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] FW: [JBoss-user] [Installation, Configuration & Deployment] - Getting 'no such file or directory
Should we drop this warning message? Its actually irrelevant since the default compilation mode for jsps is to use the eclipse version. What is javassist using for compilation? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > faisalaslam > Sent: Saturday, February 18, 2006 8:06 AM > To: jboss-user@lists.sourceforge.net > Subject: [JBoss-user] [Installation, Configuration & > Deployment] - Getting 'no such file or directory > > Hi All, > I am new to linux based JBOSS. I am using Redhat9.0 with, > JDK1.5.0_06, MYSQL 4.1.18.0 and have installed JBOSS-4.0.3SP1. > > JBOSS installation path is /usr/local/jboss-4.0.3SP1/ > > I am getting this error when I run run.sh > > here is the output i got>: > > > | run.sh: Missing file: > /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/ > usr/X11R6/bin:/root/bin:/usr/java/jdk1.5.0_06/lib/tools.jar > | run.sh: Unexpected results may occur. Make sure > JAVA_HOME points to a JDK and not a JRE. > | > | > | JBoss Bootstrap Environment > | > | JBOSS_HOME: /usr/local/jboss-4.0.3SP1 > | > | JAVA: > /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/ > usr/X11R6/bin:/root/bin:/usr/java/jdk1.5.0_06/bin/java > | > | JAVA_OPTS: -server -Xms128m -Xmx128m -Dprogram.name=run.sh > | > | CLASSPATH: > /usr/local/jboss-4.0.3SP1/bin/run.jar:/usr/local/sbin:/usr/loc > al/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin: > /usr/java/jdk1.5.0_06/lib/tools.jar > | > | > > Any idea? plz i need urgent help. > > Regards, > > -A NewJBOSSUser > > View the original post : > http://www.jboss.com/index.html?module=bb&op=viewtopic&p=39247 > 84#3924784 > > Reply to the post : > http://www.jboss.com/index.html?module=bb&op=posting&mode=repl > y&p=3924784 > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files for problems? Stop! Download the new AJAX > search engine that makes searching your log files as easy as > surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&; > dat=121642 > ___ > JBoss-user mailing list > JBoss-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-user > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Why am I seeing this in jboss-head
With a fresh update and clean build there is some port conflict going on: 10:28:44,790 WARN [ServiceController] Problem starting service jboss.remoting:s ervice=JMXConnectorServer,protocol=rmi java.rmi.server.ExportException: Port already in use: 1090; nested exception is: java.net.BindException: Address already in use: JVM_Bind at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:243) at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:178) at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:382) at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:116) at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:180) at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92) at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:78) at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:186) at org.jboss.mx.remoting.service.JMXConnectorServerService.start(JMXConnect orServerService.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher. java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.jav a:262) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController .java:991) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher. java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.jav a:262) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:190) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher. java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor. java:138) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBea nOperationInterceptor.java:140) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.jav a:262) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:190) at $Proxy8.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentSc anner.java:334) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScan ner.java:522) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doS can(AbstractDeploymentScanner.java:207) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(Abst ractDeploymentScanner.java:280) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupp ort.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBean Support.java:245) at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.M
[JBoss-dev] RE: 3.2.8 Client -> 4.0.x Compatibility
The methods added to the RMIAdaptorImpl are not correct.
getDomains should be:
public String[] getDomains() throws IOException
{
return mbeanServer.getDomains();
}
The NotificationListener base add/removeNotificationListener cannot
delegate to the RMINotificationListener versions by casting the listener
to a RMINotificationListener. These are MBeanServerConnection methods
and should be delegated to the mbeanServer.
> -Original Message-
> From: Clebert Suconic
> Sent: Sunday, February 19, 2006 3:03 PM
> To: Scott M Stark; Dimitris Andreadis
> Cc: 'jboss-development@lists.sourceforge.net'; QA
> Subject: RE: 3.2.8 Client -> 4.0.x Compatibility
>
> If changing RMIAdaptor and RMIAdaptorImpl on 3.2.8 like
> attached we solve the compatibility.
>
>
> 3.2.8.sp1 (with that change) should be compatible with
> previous versions of 3.2.8 as useFullHashMode is always false
> on 3.2.8, and therefore wouldn't be using the interface name
> on the hashMethod calculation.
>
>
> And 3.2.8.sp1 with that change will be compatible with 4.0.x
> as the interface will now match.
>
> But I had to add a few methods on RMIAdaptorImpl. I don't
> know if this is the expected semantic, so if someone could
> take a look on that please.
>
>
> Clebert
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
Dimitris, remind me why removing xalan is a problem. I'm not getting it from the discussion thread associated with this JBAS-2073 issue. From the TransformerFactory javadoc: public static TransformerFactory newInstance() throws TransformerFactoryConfigurationError Obtain a new instance of a TransformerFactory. This static method creates a new factory instance This method uses the following ordered lookup procedure to determine the TransformerFactory implementation class to load: * Use the javax.xml.transform.TransformerFactory system property. * Use the properties file "lib/jaxp.properties" in the JRE directory. This configuration file is in standard java.util.Properties format and contains the fully qualified name of the implementation class with the key being the system property defined above. * Use the Services API (as detailed in the JAR specification), if available, to determine the classname. The Services API will look for a classname in the file META-INF/services/javax.xml.transform.TransformerFactory in jars available to the runtime. * Platform default TransformerFactory instance. Neither the javax.xml.transform.TransformerFactory system property nor jre lib/jaxp.properties exists by default: [EMAIL PROTECTED] bin]$ find /usr/java/jdk1.5.0_05 -name jaxp.properties [EMAIL PROTECTED] bin]$ find /usr/java/j2sdk1.4.2_09 -name jaxp.properties -print [EMAIL PROTECTED] bin]$ so the Services API (class loader scoped resources) should dictate how the jaxp factories are found. Having the xalan.jar in lib/endorsed overrides the javax.xml.transform namespace with classes loaded from the bootstrap class loader. I don't see why we need to do this? > -Original Message- > From: Dimitris Andreadis (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Monday, February 20, 2006 4:00 AM > To: Jira Notifications > Subject: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar > from ./lib/endorsed > > [ http://jira.jboss.com/jira/browse/JBAS-2073?page=all ] > > Dimitris Andreadis updated JBAS-2073: > - > > Fix Version: (was: JBossAS-4.0.4.GA) > > I don't see how the lib/endorsed mechanism can be avoided, > when running under jdk1.4, in which case, we can't fix this > for Branch 4.x > > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
So the problem is lack of encapsulation of the essentially global org.apache.xalan.processor.TransformFactoryImpl name due to the proliferation of the xalan distribution. One should be able to work around this by introducing a org.apache.xalan.processor.TransformFactoryImpl2 that loaded the org.apache.xalan.processor.TransformFactoryImpl visible via the thread context class loader. We don't need xsl during bootstrap, and as far as I know we don't have any requirements for a specific xsl version. The jira issue is a user request to update the xalan version since we do bundle it. So maybe just dropping it and defaulting to the jdk version is the best approach. We really should avoid introducing library dependencies unless they are needed. The xalan.jar dates from jboss-3.2 and the fact that jdk1.3 had no bundled xsl implementation. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Dimitris Andreadis > Sent: Monday, February 20, 2006 12:39 PM > To: jboss-development@lists.sourceforge.net > Subject: RE: [JBoss-dev] FW: [JBoss JIRA] Updated: > (JBAS-2073) Remove xalan.jar from ./lib/endorsed > > > What I'm saying is under jdk1.4 the only way to override the > jdk embedded xalan with a different version is to drop it in > lib/endorsed or use a scoped deployment. > > Putting it in server/xxx/lib or server/xxx/deploy won't work, > even if specifying the javax.xml.transform.TransformerFactory > property since setting it to > org.apache.xalan.processor.TransformFactoryImpl makes no > difference, it will just load the jdk provided xalan version > because the class names collide. > > Now, I had the feeling that we *needed* a xalan.jar version > newer than the one provided with jdk1.4, in which case, what > other way we would have to override the jdk version? The > rules you mention would work, if the overriding xalan version > used different class names! > > I just removed lib/endorsed/xalan.jar and the server seems to > boot happily. If we *do not need* a newer version, I guess we > can just remove it, and let the user drop its own > lib/endorsed/xalan.jar version, if necessary. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] This is the type of dependency info every project on labs.jboss.org
This type if info on dependecies (the license needs to be added as well and the project url cannot be empty) is what every project in labs.jboss.org should have: http://groovy.codehaus.org/dependencies.html This should be generated from the project thirdparty dependency declarations. Scott Stark VP Architecture & Technology JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
> The org.apache.xalan.processor.TransformFactoryImpl visible > through the TCL, for a non-scoped deployment, wouldn't be > again the JDK bundled xalan, since this is loaded with the > Bootstrap CL? (testing my CL knowledge here :) > Not necessarily because the org.apache.* is not a jdk core classes. Neither are the javax.* nor bundled org.* classes. All of those can be created in a scoped context by a class loader that does not delegate to its parent. Only classes in the java.* namespace cannot be passed to the ClassLoader.defineClass method. When this does not work is when you have mixing of classes with static references to jdk bootstrap classes in a class that is being used across different class loaders. There is no notion of "redefine class on inconsistent type system usage" although there should be in server environments. > > Fine, I'll remove it and see if anyone complaints :) > > Maybe we should go for an 4.0.4.RC2, too. That is probably a good idea. Two weeks for CR2(RC2 is now bad, I'll update the jboss version usage today), and the GA in 3-4 weeks after that. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Status of groovy in jdk6
Gavin made me look at groovy for things like closures, and the groovy site shows a pervasive set of changes in the core jdk classes to support things like groovy.lang.Range, groovy.lang.Closure: http://groovy.codehaus.org/groovy-jdk.html but the associated jsrs don't seem far along: http://www.jcp.org/en/jsr/detail?id=241 http://www.jcp.org/en/jsr/detail?id=223 I should probably know this but I don't see anything on the jdk6 eg, and the jdk6 beta has nothing in the apis for groovy as yet. Anyone know more about its status? The related question I have is whether closures are something that make sense in javassist/aop as a more abstract representation of the behavior of an aspect. This could be used to cleanup code reuse in boilerplate aspects like security. Today they only differ in the interceptor/aspect invoke signature. Scott Stark VP Architecture & Technology JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Xalan removal saga
The question is where the the xml-apis.jar come from then? It should not include a TransformerFactory if its not from the xalan distribution which is what I suspect. The origin of the xml jars needs to be validated and if the xerces distribution defaults to configuring a TransformerFactory, that should be removed. The xml parser is needed to override the buggy jdk version. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Dimitris Andreadis > Sent: Tuesday, February 21, 2006 2:12 AM > To: jboss-development@lists.sourceforge.net > Subject: [JBoss-dev] Xalan removal saga > > > I tried to remove lib/endorsed/xalan.jar in 4.0.x and the > situation is as follows: > > Works fine under jdk1.5, but breaks under jdk5 when the > XSLSubDeployer does a > > TransformerFactory tf = TransformerFactory.newInstance(); > > The problem is lib/endorsed/xml-apis.jar includes a > javax.xml.transform.TransformerFactory that simply points to > org.apache.xalan.processor.TransformerFactoryImpl, if the > javax.xml.transform.TransformerFactory property is not set! > > And that overrides the jdk5 > javax.xml.transform.TransformerFactory that points to > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl. > > If (when run under jdk5) I set > -Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xa > lan.intern > al.xsltc.trax.TransformerFactoryImpl, but I don't know if > this should work with all jdk5 jdks. > > What options do we have? Hack xml-apis to remove the > offending javax.xml.transform.TransformerFactory class? > > If I remove lib/endorsed/xml-apis.jar too, things work fine > under jdk5, but fail under jdk1.4 with: > > 11:55:07,657 INFO [Server] Root Deployment Filename: > jboss-service.xml > Warning: Caught exception attempting to use SAX to load a SAX > XMLReader > Warning: Exception was: org.xml.sax.SAXException: System > property org.xml.sax.dr iver not specified > Warning: I will print the stack trace then carry on using the > default SAX parser > > org.xml.sax.SAXException: System property org.xml.sax.driver > not specified > at > org.xml.sax.helpers.XMLReaderFactory.createXMLReader(XMLReaderFactory > .java:90) > at org.dom4j.io.SAXHelper.createXMLReader(SAXHelper.java:83) > at org.dom4j.io.SAXReader.createXMLReader(SAXReader.java:894) > at org.dom4j.io.SAXReader.getXMLReader(SAXReader.java:715) > at org.dom4j.io.SAXReader.read(SAXReader.java:435) > at org.dom4j.io.SAXReader.read(SAXReader.java:291) > at > org.jboss.mx.metadata.XMLMetaData.build(XMLMetaData.java:255) > at org.jboss.mx.modelmbean.XMBean.(XMBean.java:253) > at org.jboss.mx.modelmbean.XMBean.(XMBean.java:282) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct > orAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC > onstructorAccessorImpl.java:27) > at > java.lang.reflect.Constructor.newInstance(Constructor.java:274) > at > org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java: > 1233) > at > org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java: > 286) > at > org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java: > 344) > at > org.jboss.system.server.ServerImpl.createMBean(ServerImpl.java:532) > at > org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:438) > at > org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) > at org.jboss.Main.boot(Main.java:200) > at org.jboss.Main$1.run(Main.java:464) > at java.lang.Thread.run(Thread.java:534) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Xalan removal saga
This is probably a jaxp requirement to not subset the apis. The next question is whether the xml-apis.jar is needed. Is jdk1.4.x at jaxp 1.2? The xerces 2.7.x release supports jaxp 1.3. The potential problem with doing this is are there dependencies between the javax.xml.transform.* classes and the other javax.xml.* classes. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Dimitris Andreadis > Sent: Tuesday, February 21, 2006 3:07 PM > To: jboss-development@lists.sourceforge.net > Subject: RE: [JBoss-dev] Xalan removal saga > > > I traced this down to a TranformerFactory included in the > xml-apis.jar that comes with xerces tools (e.g. > Xerces-J-tools.2.7.1.zip). > > This is tagged as 1.3.02 and in turn originates from > http://xml.apache.org/commons/ > > The xml-commons hadn't had any releases for some time, so the > tagged xml-apis.jar comes directly from their cvs. > > I think I will remove all javax.xml.transform.** from > xml-apis.jar to create a new xml-apis-no-transform.jar and > include this instead. > > From a quick test it seems to be working with both jdk1.4 and jdk5. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Xalan removal saga
The more I think about it the more I doubt this is legal for a java ee distribution. If we are bundling jaxp 1.3, we need it to be the complete 1.3 set of apis and we would just have to patch the TranformerFactory to do the right thing, whatever that is. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Dimitris Andreadis > Sent: Tuesday, February 21, 2006 3:07 PM > To: jboss-development@lists.sourceforge.net > Subject: RE: [JBoss-dev] Xalan removal saga > > > I traced this down to a TranformerFactory included in the > xml-apis.jar that comes with xerces tools (e.g. > Xerces-J-tools.2.7.1.zip). > > This is tagged as 1.3.02 and in turn originates from > http://xml.apache.org/commons/ > > The xml-commons hadn't had any releases for some time, so the > tagged xml-apis.jar comes directly from their cvs. > > I think I will remove all javax.xml.transform.** from > xml-apis.jar to create a new xml-apis-no-transform.jar and > include this instead. > > From a quick test it seems to be working with both jdk1.4 and jdk5. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] integrating jbpm into jboss build
No, this should not be installed in the server build structure. It needs to be integrated into a testsuite/src/resources/test-configs that jbossws uses. I created the following build forum post on this. http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3925623#3925623 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Tom Baeyens > Sent: Wednesday, February 22, 2006 1:52 AM > To: jboss-development@lists.sourceforge.net > Subject: [JBoss-dev] integrating jbpm into jboss build > > i'm planning to integrate jbpm into the main jboss build. > the occasion is that JBossWS wants to run BPEL integration > tests as part of the overall jboss test suite. > > i already added jbpm to the jboss repository (without version > in the jar name :-s ) > > should i add a target in the main jboss-head/build/build.xml > that installs the jbpm service archive in the all configuration ? > > should i add jbpm as part of the all configuration ? > > what branches should i take into account ? > > any other procedures i should be aware of ? > > regards, tom. > [EMAIL PROTECTED] > +32 14 880 900 > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files for problems? Stop! Download the new AJAX > search engine that makes searching your log files as easy as > surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Xalan removal saga
Setting this via a system property cannot be done as this is a global override. We could simply externalize the default factory name to an attribute of the jboss server info mbean and fallback to the jdk default if it cannot be found. I don't know if an extension class can get access to a class from the jdk rt.jar via the ClassLoader.getSystemClassLoader(). > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Dimitris Andreadis > Sent: Wednesday, February 22, 2006 4:02 AM > To: jboss-development@lists.sourceforge.net > Subject: RE: [JBoss-dev] Xalan removal saga > > It all boils down to here: > ... > return (TransformerFactory) FactoryFinder.find( > /* The default property name according to the JAXP spec */ > "javax.xml.transform.TransformerFactory", > /* The fallback implementation class name */ > "org.apache.xalan.processor.TransformerFactoryImpl"); > ... > > I don't see how we can patch the TF to return a proper > fallback implementation name, because we just don't know what that is. > > On Sun jdk1.4 it would be > org.apache.xalan.processor.TransformerFactoryImpl > On Sun jdk5 it would be > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl > But on other vendor jdks, whats the correct value? > > And if it is just a question of setting a sensible default > value, we could do just the same setting the > javax.xml.transform.TransformerFactory property. > > But isn't this exactly the role of the TransformerFactory > offered by the jdk vendor? > > I think the best compromise is to just remove > javax.xml.transform.TransformerFactory from xml-apis.jar > (replace with xml-apis-notf.jar ?) to let the vendor supplied > default apply. > > I've attached the TransformerFactory code that comes with xml-apis.jar --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Xalan removal saga
Its not clear that removal of the javax.xml.transform.* is safe. There are references to org.w3c.dom.* from the javax.xml.transform.dom for example. We cannot simply remove just the javax.xml.transform.TransformerFactory. It would have to be all javax.xml.transform.* classes. The presence of the javax.xml.transform.TransformerFactory should not affect a user being able to override the transformer by dropping in an xsl jar with a META-INF/services/javax.xml.transform.TransformerFactory entry as this takes precedence over the TransformerFactory defaults. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Dimitris Andreadis > Sent: Wednesday, February 22, 2006 9:24 AM > To: jboss-development@lists.sourceforge.net > Subject: RE: [JBoss-dev] Xalan removal saga > > > I don't follow why this is necessary. If we just remove > javax.xml.transform.TransformerFactory from xml-apis.jar then > the jdk bundled TransformerFactory will be used to choose the > correct implementation. > > A user can always drop his own xalan.jar to lib/endorsed (for > jdk1.4/5), or server/xxx/lib for jdk5, or use a scoped > xalan.jar to override the jdk version, since xalan.jar contains: > > META-INF/services/javax.xml.transform.TransformerFactory file > containing the class name of its implementation. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Scott M Stark > > Sent: 22 February, 2006 18:16 > > To: jboss-development@lists.sourceforge.net > > Subject: RE: [JBoss-dev] Xalan removal saga > > > > Setting this via a system property cannot be done as this > is a global > > override. We could simply externalize the default factory > name to an > > attribute of the jboss server info mbean and fallback to the jdk > > default if it cannot be found. I don't know if an extension > class can > > get access to a class from the jdk rt.jar via the > > ClassLoader.getSystemClassLoader(). > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files for problems? Stop! Download the new AJAX > search engine that makes searching your log files as easy as > surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossCache 1.2.4.SP2 released
http://jira.jboss.com/jira/browse/JBAS-2789 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dimitris AndreadisSent: Wednesday, February 22, 2006 10:02 AMTo: jboss-development@lists.sourceforge.netSubject: RE: [JBoss-dev] JBossCache 1.2.4.SP2 released Ruel, have you created a JIRA task for the upgrade? Just so it goes into the release notes. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruel LoehrSent: 22 February, 2006 19:57To: jboss-development@lists.sourceforge.netSubject: [JBoss-dev] JBossCache 1.2.4.SP2 released JBossCache version 1.2.4.SP2 has been released. This can be downloaded from: http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=102339 and is also available in the repository. Both the jboss-head and jboss-4.0.x branches have been updated to use this new version. Ruel Loehr JBoss QA
RE: [JBoss-dev] Xalan removal saga
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Dimitris Andreadis > Sent: Wednesday, February 22, 2006 1:09 PM > To: jboss-development@lists.sourceforge.net > Subject: RE: [JBoss-dev] Xalan removal saga > > > Removing javax.xml.transform.TransformerFactory or patching > it to try invoke the underlying TransformerFactory (if this > is possible) which is essentially the same thing, is > undesirable because you'll end up with a transformer API and > an underlying implementation that may not match > (correct?) > This is always the case though. Any attempt to override the xsl factory will be subject to matching the javax.xml.transform.* in effect. > Removing javax.xml.transform.* is not clear that is safe (I > guess because you might have incompatible parser api+impl <-> > transformer > api+impl interactions?) > > Ok, we are doomed :) There are some xml parser class dependencies in the javax.xml.transform.dom and javax.xml.transform.sax packages. I just don't know if the javax.xml.transform.* in jaxp 1.3 can use the 1.2 xml parsers. It's a tradeoff between introducing a xsl parser dependency that the user may not want vs modifying the TransformerFactory to be more flexible at the cost of the user potentially have to configure the TransformerFactory default. I think modifying the TransformerFactory is the most flexible, but maybe just bundling the xsl parser is the simplest. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Finalizing the Release of JBAS 3.2.8.SP1 & 4.0.4.GA - YourHelp is Needed
The new jta code is not fully cleaned and in a public repository. Need to check with Mark/Kevin to see if this is still on target for a 4.0.4 release next month. > -Original Message- > From: Adrian Brock > Sent: Friday, February 24, 2006 8:48 AM > To: Dimitris Andreadis > Cc: jboss-development@lists.sourceforge.net; Architect > Council; QA; Scott M Stark; Ivelin Ivanov > Subject: Re: Finalizing the Release of JBAS 3.2.8.SP1 & > 4.0.4.GA - YourHelp is Needed > > The JCA, JTA and JMS work is pretty much done. > > The outstanding stuff is all testing, some just to prove > there is still no problem on bugs already fixed. > > But this also includes the big one, > i.e. testing JMS inflow. > > Incidently, I thought there would be some tasks raised for > JBoss Transactions before the 4.0.4 release was finalized? > > On Fri, 2006-02-17 at 12:31, Dimitris Andreadis wrote: > > Hello everybody, > > > > We have scheduled 2 releases of JBoss AS: > > > > v3.2.8.SP1 for 03/Mar/06 (i.e. in 2 weeks time) v4.0.4.GA for > > 17/Mar/06 (i.e. in 4 weeks time) > > > > 3.2.8SP1 is needed to address a couple of issues with 3.2.8 > (JBossMQ > > -already fixed- and some extra interop scenarios with 4.0.2 > versions, > > plus whatever appears within the next 2 weeks), so it's > under control. > > > > However, getting 4.0.4.GA out the door is a big challenge > as we have > > about 290 issues open! This list needs to be reduced to a > manageable > > size of 90 or less issues to be solved until the release date. > > > > We need EVERYONE to have a close look at the JBAS JIRA > tasks related > > to his area of interest in order to: > > > > 1) Decide what features/bug/task are really important to go > out with > > 4.0.4. > > > > Remember, 4.0.4RC1 is already out so new features shouldn't > really be > > included between RC1 and GA, unless absolutely necessary, so we are > > talking about bug fixing mostly. > > > > Please make use of the task Priorities to increase to > "Critical" the > > priority of the tasks you want to get done for 4.0.4, and > decrease to > > "Minor" those you don't. > > > > 2) Assign the issues to yourself or a member of your team; allocate > > time to work and close those critical issues within the > next 3 WEEKS > > (to leave some time for testing). > > > > If you don't have time to work on those tasks, keep them unassigned > > and either postpone those for 4.0.5.CR1, or if something is never > > going to get fixed just close it as such with an explanation. > > > > If it still something important that you don't have time to work on > > and we must look at, RAISE the issue in the DEV list so we find > > someone to work on it. > > > > Again, please raise any issues, especially integration ones > EARLY in > > the DEV and QA lists. > > > > Thanks for all your help in advance. > > > > /Dimitris > -- > > Adrian Brock > Chief Scientist > JBoss Inc. > > > --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Finalizing the Release of JBAS 3.2.8.SP1 & 4.0.4.GA - YourHelp is Needed
There still is the question of if option==true, does it actually work. That is the integration task issue. > -Original Message- > From: Dimitris Andreadis > Sent: Friday, February 24, 2006 12:40 PM > To: Scott M Stark; Adrian Brock > Cc: 'jboss-development@lists.sourceforge.net'; Architect > Council; QA; Ivelin Ivanov > Subject: RE: Finalizing the Release of JBAS 3.2.8.SP1 & > 4.0.4.GA - YourHelp is Needed > > > Isn't the new Transaction Manager supposed to be an optional > plug-in offered seperately, at this stage? > > This is what I gathered from the integration plan: > > http://jira.jboss.com/jira/browse/JBTM-13 > > I can't find any integration tasks in JIRA. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Finalizing the Release of JBAS 3.2.8.SP1 & 4.0.4.GA - YourHelp is Needed
At a minimum there needs to be a placeholder issue in the http://jira.jboss.com/jira/browse/JBAS project that links to the JBTM issues that need to be completed. Otherwise 4.0.4.GA can go out without anyone actually testing the integration. Beyond that, is this going to be integrated into the installer? If it is, then we also need an integration test in the jbossas testsuite. > -Original Message- > From: Mark Little [mailto:[EMAIL PROTECTED] > Sent: Saturday, February 25, 2006 5:19 AM > To: Dimitris Andreadis > Cc: Scott M Stark; Adrian Brock; > jboss-development@lists.sourceforge.net; Architect Council; > QA; Ivelin Ivanov > Subject: Re: Finalizing the Release of JBAS 3.2.8.SP1 & > 4.0.4.GA - YourHelp is Needed > > So it depends what you expect to see. > http://jira.jboss.com/jira/browse/JBTM-2 is one example of > the tasks left. You need to remember that the main > integration effort was done months ago in Arjuna, who've been > selling the integrated components for a few years. What we're > doing here is a rebadge to JBoss Transactions and 4.0.4. > Unless there are major differences between 4.0.2 and 4.0.4 > that directly affect TS then these tasks should be sufficient > to cover the integration effort. > > Mark. > > > Dimitris Andreadis wrote: > > Isn't the new Transaction Manager supposed to be an optional plug-in > > offered seperately, at this stage? > > > > This is what I gathered from the integration plan: > > > > http://jira.jboss.com/jira/browse/JBTM-13 > > > > I can't find any integration tasks in JIRA. > > > > > >> -Original Message- > >> From: Scott M Stark > >> Sent: 24 February, 2006 21:43 > >> To: Adrian Brock; Dimitris Andreadis > >> Cc: jboss-development@lists.sourceforge.net; Architect > >> Council; QA; Ivelin Ivanov > >> Subject: RE: Finalizing the Release of JBAS 3.2.8.SP1 & > >> 4.0.4.GA - YourHelp is Needed > >> > >> The new jta code is not fully cleaned and in a public > >> repository. Need to check with Mark/Kevin to see if this is > >> still on target for a 4.0.4 release next month. > >> > >> > >>> -Original Message- > >>> From: Adrian Brock > >>> Sent: Friday, February 24, 2006 8:48 AM > >>> To: Dimitris Andreadis > >>> Cc: jboss-development@lists.sourceforge.net; Architect > Council; QA; > >>> Scott M Stark; Ivelin Ivanov > >>> Subject: Re: Finalizing the Release of JBAS 3.2.8.SP1 & > 4.0.4.GA - > >>> YourHelp is Needed > >>> > >>> The JCA, JTA and JMS work is pretty much done. > >>> > >>> The outstanding stuff is all testing, some just to prove there is > >>> still no problem on bugs already fixed. > >>> > >>> But this also includes the big one, > >>> i.e. testing JMS inflow. > >>> > >>> Incidently, I thought there would be some tasks raised for JBoss > >>> Transactions before the 4.0.4 release was finalized? > >>> > >>> On Fri, 2006-02-17 at 12:31, Dimitris Andreadis wrote: > >>> > >>>> Hello everybody, > >>>> > >>>> We have scheduled 2 releases of JBoss AS: > >>>> > >>>> v3.2.8.SP1 for 03/Mar/06 (i.e. in 2 weeks time) v4.0.4.GA for > >>>> 17/Mar/06 (i.e. in 4 weeks time) > >>>> > >>>> 3.2.8SP1 is needed to address a couple of issues with 3.2.8 > >>>> > >>> (JBossMQ > >>> > >>>> -already fixed- and some extra interop scenarios with 4.0.2 > >>>> > >>> versions, > >>> > >>>> plus whatever appears within the next 2 weeks), so it's > >>>> > >>> under control. > >>> > >>>> However, getting 4.0.4.GA out the door is a big challenge > >>>> > >>> as we have > >>> > >>>> about 290 issues open! This list needs to be reduced to a > >>>> > >>> manageable > >>> > >>>> size of 90 or less issues to be solved until the release date. > >>>> > >>>> We need EVERYONE to have a close look at the JBAS JIRA > >>>> > >>> tasks related > >>> > >>>> to his area of interest in order to: > >>>> > >
[JBoss-dev] RE: RE: Finalizing the Release of JBAS 3.2.8.SP1 & 4.0.4.GA - YourHelp is Needed
Ok, so you are responsible for the integration with 4.0.4.GA, but it sounds like we need to flesh out what integration apis need to be tested for stability without have to replace the tm and rerun every test that touches the tm. > -Original Message- > From: Kevin Conner [mailto:[EMAIL PROTECTED] > Sent: Monday, February 27, 2006 6:08 AM > To: Scott M Stark > Cc: Mark Little; Dimitris Andreadis; Adrian Brock; > jboss-development@lists.sourceforge.net; QA; Ivelin Ivanov > Subject: Re: RE: Finalizing the Release of JBAS 3.2.8.SP1 & > 4.0.4.GA - YourHelp is Needed > > Scott M Stark wrote: > > At a minimum there needs to be a placeholder issue in the > > http://jira.jboss.com/jira/browse/JBAS project that links > to the JBTM > > issues that need to be completed. Otherwise 4.0.4.GA can go out > > without anyone actually testing the integration. > > > > Beyond that, is this going to be integrated into the > installer? If it > > is, then we also need an integration test in the jbossas testsuite. > > I do not believe we are a dependency of 4.0.4 GA, rather it > is us who will depend on 4.0.4 GA. > > The intention is to integrate the JTA and JTS components of > Arjuna into the JBoss 4 stream for the end of March and to > distribute this initial release separately to the AS, using > an installer if time permits. > > I'm not sure whether future releases will fall into step with > JBoss 4 releases but, if they do, I will integrate the TS > component into the AS installer and change the testsuite to > execute using each transaction manager. > > I have been running the JBoss testsuite as the integration > test, are there other integration tests I should be aware of? > (The unit testing is done using the Arjuna QA tests). > > Kev > --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
