Menu
▾
▴
jboss-dev-forums — The jboss development forum posts
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
| 2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
| 2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
| 2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
| 2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
| 2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
| 2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
| 2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
| 2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <sco...@jb...> - 2005-04-27 01:00:02
|
Ok, that is what I figured. Where is the thirdparty repository being populated from? Another baby step to getting the build integrated would be to actually build the 4.0 branch thirdparty contents from a checkout of the thirdparty repository. That way, there would be a single declarative statement in the form of a build file that defined what is going into a given 4.0.x release in terms of the thirdparty elements. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875521#3875521 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875521 |
|
From: <cle...@jb...> - 2005-04-26 23:30:52
|
As for http://jira.jboss.com/jira/browse/JBAS-1598, I'm creating a TestSuite that will execute a bunch of defined tests against 4.0.1 and 4.0.0. In other words, we will execute tests against current version using client libraries from 4.0.0 and them 4.0.1. The problem I'm having now is to define what's the basic set of tests I could use in that suite. Right now I'm using everything defined into "tests-standard-unit" and this seems to be huge. So... if you have any clue for shrinking the number of tests used int that list will be more than welcome. I guess we want basically test client libraries, so I guess we will have to execute mostly remote tests. Thanks, Clebert Suconic View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875518#3875518 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875518 |
|
From: <rya...@jb...> - 2005-04-26 23:26:46
|
This was an accomodation for testing the new build in jboss-head. The id of a component points to its location in the thirdparty directory. Now that we are populating thirdparty from the repository, I will need to decompose apache commons into individual components which can have their own versions. <component id="apache-commons-logging" | licenseType="apache-2.0" | version="1.2" | projectHome="http://jakarta.apache.org/commons/index.html"> | <artifact id="commons-logging.jar"/> | </component> | <component id="apache-commons-httpclient" | licenseType="apache-2.0" | version="1.3" | projectHome="http://jakarta.apache.org/commons/index.html"> | <artifact id="commons-httpclient.jar"/> | </component> This will also involve going in to each jbossbuild.xml and determining which parts of apache-commons it depends on and changing the <source id="main"> | <include component="apache-commons"/> to <source id="main"> | <include component="apache-commons-logging"/> http://jira.jboss.com/jira/browse/JBBUILD-69 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875517#3875517 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875517 |
|
From: <dim...@jb...> - 2005-04-26 22:41:43
|
I've made an org.jboss.system.BarrierController service based on Scott's StartGroup idea about a programmatically controlled barrier mbean.
The main differences are:
(a) The barrier being more "jboss like" so it exposes "State/StateString" attributes and produces AVCs
(b) I've used the generic ListenerServiceMBeanSupport to subscribe to any mbean/notification combination and utilized the subscription 'handback' to associate the reception of any notification from that subscription with the starting/stoping of the barrier. This allows for very flexible usage scenarios, for example, I can trigger a start when the tomcat connectors are created, and a stop when the server shuts down:
| <mbean code="org.jboss.system.BarrierController"
| name="jboss:service=BarrierController">
| <attribute name="BarrierObjectName">jboss:name=TomcatConnector,type=Barrier</attribute>
| <attribute name="StartBarrierHandback">start</attribute>
| <attribute name="StopBarrierHandback">stop</attribute>
| <attribute name="SubscriptionList">
| <subscription-list>
| <mbean name="jboss.web:service=WebServer" handback="start">
| <filter factory="NotificationFilterSupportFactory">
| <enable type="jboss.tomcat.connectors.started"/>
| </filter>
| </mbean>
| <mbean name="jboss.system:type=Server" handback="stop">
| <filter factory="NotificationFilterSupportFactory">
| <enable type="org.jboss.system.server.stopped"/>
| </filter>
| </mbean>
| </subscription-list>
| </attribute>
| </mbean>
|
(c) Another difference is that I bring intially the Barrier to the CREATED state, instead of just registering it. This seems a little more natural to me, because the services that depend on the "Barrier" essentially wait for an event to trigger their complete start (or stop). This maps well with the manual startBarrier()/stopBarrier() too.
In addition we can easily avoid the deployment error printout by the Scanner/MainDeployer by changing the ServiceController to *not* report as incompletely deployed those services in the CREATED state:
| public List listIncompletelyDeployed()
| {
| List id = new ArrayList();
| for (Iterator i = installedServices.iterator(); i.hasNext();)
| {
| ServiceContext sc = (ServiceContext) i.next();
| if (sc.state != ServiceContext.RUNNING && sc.state != ServiceContext.CREATED)
| {
| id.add(sc);
| }
| }
|
| return id;
| }
|
I haven't committed this last bit yet, but it seems sensible to me that services in the CREATED state are not really in error. In addition, as it is now, this can happen only through programmatic deployments, like this barrier trick, since normal deployment (through the MainDeployer) will always try to bring the deployment to RUNNING or FAILED state (or CONFIGURED in presence of a dependency).
Any objections for this?
I find the usage of a handback string instead of a notification type, rather interesting as well, because you can have more than one events from different MBeans triggering the start/stop of the barrier.
I think I'll add the ability to specify the initial state of the barrier (started or stopped), to cater for those cases where you might have lost the starting notification. For more complex scenarios this should be overridable by subclassing the BarrierControler.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875510#3875510
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875510
|
|
From: <sco...@jb...> - 2005-04-26 22:24:36
|
How is the version info supposed to be tracked in the thirdparty? I'm updating the commons jars and I don't see any version info for the jars listed in this. These jars are basically indepdendent so there is no single version here. | <project name="apache-commons-component-info"> | | <!-- ============================================================ --> | <!-- Apache Commons --> | <!-- ============================================================ --> | | <component id="apache-commons" | licenseType="apache-2.0" | version="mixed" | projectHome="http://jakarta.apache.org/commons/index.html"> | | <artifact id="commons-logging.jar"/> | <artifact id="commons-httpclient.jar"/> | <artifact id="commons-discovery.jar"/> | <export> | <include input="commons-logging.jar"/> | <include input="commons-httpclient.jar"/> | <include input="commons-discovery.jar"/> | </export> | </component> | </project> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875502#3875502 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875502 |
|
From: dlsa <nu...@jb...> - 2005-04-26 22:16:23
|
Hello, I was wondering if it could be possible / make any sense to propagate the exceptions thrown inside the ServerInvocationHandler implementors invoke method, to the client. This would make the client code more clean. Regards View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875501#3875501 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875501 |
|
From: <aco...@jb...> - 2005-04-26 21:37:59
|
So guys, we can't let this linger until the end of the year the way I'd planned. Lets reprioritize and nail what we need for a marketable 1.0 mail server and then lets make this the cutting board for milestone releases. * Stabilize our current stuff - (Mailboxes and blobs, etc) * Security - Basic association of security (roles association for Create, Delete for mailboxes, role association for SEND) should work with jboss login modules. Do this in JAAS and its done. * Virtual Hosts - aco...@jb... != aco...@fe... * IMAP - basic IMAP for mail server support * traditional spam filtering support - just someone needs to write the mail listener * JCA - needs to be JCA adapter for sending/receiving mail * WebMail - need to have at least a disconnected traditional webmail (later we should have a "direct connected" * Mail Lists - including adminsitration features * Mail Forwarding - let users forward their mail elsewhere * Mail routing - set this up as a middle tier mail server * "clusterable" - in a "won't break" in a cluster sense of the word (but nothing specific) * Load test - should handle load. * Installation - easy installation * Administration - easy administration, possibly work with JBoss Admin Console folks 2.0: * Mail API standardization - meaning a more sensible "user" api for writing mail listeners * REST support * Exchange integration * Calendar * Mail Scripting * NIO and other non 1.4 pie in the sky stuff * Exchange class adminstration * High end clustering/caching * Bigger spam tools (fingerprints, etc) * ... etc. I'm going to start aiming the milestones at that in 1.0 instead of the "big picture" that will be 2.0. My original opinion was that we wouldn't be able to really be marketable until we had the whole thing; however, with interest building and usage already starting I want to be able to bring people into professional development sooner rather than later. Building a bigger base really means having a release that we're comfortable "blessing" as production. Then we deal with real users, real support and pain. Thoughts? Questions? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875497#3875497 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875497 |
|
From: <aco...@jb...> - 2005-04-26 21:18:58
|
Guys were kinda fermenting on this release (in a negative wild yeast manner). I went on the back channels to ping some guys on the mailbox/mailstore integration so we can get MySQL up. We need to move that forward so we can get the pre out. I'm working myself on decoupling the MailListenerChain from SMTP so that we can plug it in at different points. Nearly finished. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875495#3875495 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875495 |
|
From: marceloverdijk <nu...@jb...> - 2005-04-26 20:49:49
|
Enabling JSP compilation does the trick. See http://jboss.com/index.html?module=bb&op=viewtopic&p=3875492#3875492 To bad I couldn't find anything about this in the documentation, wiki or forums. Cheers, Marcel View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875493#3875493 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875493 |
|
From: <tom...@jb...> - 2005-04-26 20:25:38
|
Don't know if is what you are looking for, but I added ability for remote, multi process testing based off of JUnit framework in the jboss-benchmark project. I will be using this to replace the distributed test framework under jboss remoting for the remoting tests. Can find more info on it at http://www.jboss.org/wiki/Wiki.jsp?page=JBoss_Benchmark_jrunit. I just added it last week and have not started migrating the remoting tests to use it yet, so can't say how stable it is at this point. Feel free to use it or improve on it as needed. Don't know when Clebert will be doing an official release of jboss-benchmark, so don't know when official binary for this will be available. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875491#3875491 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875491 |
|
From: <tom...@jb...> - 2005-04-26 20:00:47
|
I am working on converting my test.functional target from the old JBossRemoting build to the new jboss build. The old one looks like:
<target name="tests.functional" depends="tests.jars">
| <mkdir dir="${output.tests.results}"/>
| <junit printsummary="true" fork="yes" includeantruntime="true">
| <classpath>
| <path refid="tests.classpath"/>
| <pathelement location="${output.lib.dir}/jboss-remoting-tests.jar"/>
| </classpath>
| <!-- this is needed for the remoting.marshall.dynamic.remote.MarshallerLoadingServer -->
| <jvmarg value="-Dloader.path=${output.lib.dir}/jboss-remoting-loading-test.jar"/>
| <formatter type="xml"/>
| <batchtest fork="yes" todir="${output.tests.results}"
| haltonfailure="no">
| <formatter type="xml"/>
| <fileset dir="${tests.compile.dir}">
| <include name="**/remoting/**/*TestCase.class"/>
| <exclude name="**/remoting/**/performance/**"/>
| </fileset>
| </batchtest>
| </junit>
| </target>
|
There are few specializations I need. First, is want to specifiy exactly what will be included on the classpath for the test run (so jboss-remoting-loading-test.jar is not included). Then want to pass a jvmarg indicating where the jboss-remoting-loading-test.jar is located (this is a for a test of remote classloading).
My jbossbuild.xml currently looks like:
<source id="tests" test="org/jboss/test/remoting/**/*TestCase.java">
| <include input="main"/>
| <include component="apache-commons"/>
| <include component="oswego-concurrent"/>
| <include component="apache-log4j"/>
| <include component="junit-junit"/>
| <include component="sun-jmx"/>
| <include component="sun-jaxp"/>
|
| <include component="javagroups-javagroups"/>
|
| <include component="common"/>
| <include component="naming"/>
| <include component="j2se"/>
| <include component="system"/>
| <include component="aop"/>
| </source>
I am still not totally clear on the source tags and what exactly they are defining (can these be any free form strings, or do they have to be 'main', 'test', etc.?). I found where specifing a 'test' attribute with the string expresession for the test you want run will be used within the 'runtest' targetdef from task.xml (which will indeed run my tests when run the 'test' target for the build.
So now just need to be able to specify exactly the jars included on the classpath for the test run and how to pass the jvmarg parameter. I see that runtest uses pathElements for the classpath, but don't know where the values come from. I guess the jvmarg can be added to the runtest taskdef as well, but am not sure how to make it conditional depending of if there is a variable defined for it within the jbossbuild.xml.
Thanks.
-Tom
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875489#3875489
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875489
|
|
From: zsoltvincze <nu...@jb...> - 2005-04-26 19:28:44
|
I have to admit first off that Webservices isbrand new to me. Anyway, I got a WSDL file and I'm trying to see what the process ofthe creation of aWS client would be. I open the new Webservice client wizard and specify the WSDL file. The NEXT button remains greyed out but the finish is available so I hit thet and I get a anonymous wrote : Creation of element failed. | | javax/xml/encoding/TypeMapping message. That's all. I have no idea if I'm missing something or what else. Could someone help out? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875487#3875487 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875487 |
|
From: <rya...@jb...> - 2005-04-26 19:13:02
|
The component-info allows other components to reference your artifacts. It also allows you to create an artifactdef for that artifact in your jbossbuild.xml. IE, it must be declared before it can be implemented. The release.xml (toplevel build) dictates your release structure, as well as what jars should be downloaded upon synchronize. However, it doesn't seem like you want these jars in your release and since you are building the remoting component from source, they won't be downloaded. So in this case, there is no practical value in adding these artifacts to the component definition in your release.xml. That said, I think it's a good idea to keep these two in sync for now. I realize that this duplication is evil. I will detail in another thread where I think we should take the toplevel build. But for now, we should move forward with what we have and keep these two component declarations in sync. Regarding the includes element in the release.xml. This was obsoleted by the component-info's export element. You should remove this from your release.xml for *all* components. I apologize for not doing this earlier as it just confuses the issue. So your release.xml should look like this: | <component id="remoting" | module="jboss-remoting" | version="5.0-SNAPSHOT" | > | <artifact id="jboss-remoting.jar" release="lib"/> | <artifact id="jboss-remoting-tests.jar"/> | <artifact id="jboss-remoting-loading-tests.jar"/> | </component> | <!-- no includes id=remoting-project here --> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875484#3875484 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875484 |
|
From: timfox <nu...@jb...> - 2005-04-26 18:44:41
|
Hi All- I've submitted a patch to JIRA. The patch contains: Completion of JBossConnection with the exception of the connection consumer stuff. This includes the exception listener set/get stuff which I am intercepting in the ConnectionInterceptor and storing in meta data. I haven't added the code that actually catches exceptions on the connection and sends them to the listener. I notice that this doesn't seem to be implemented in Spy anyway. The ClosedInterceptor is also implemented and I've added a Hierarchy interceptor to maintain the Connection->Session->Producer/Consumer hierarchy. JBossMessageProducer is also fully implemented with the exception of get/set TimeToLive and get/set Priority. They seem trivial to implement but I guess there might be a catch here so I've left them for now. JBossSession is also implemented with the exception of the different createMessage methods, the get/set MessageListener, the run() method, durable subscriber stuff, temporary destinations, and browser stuff. This includes transacted session stuff although the implementation is incomplete. So far I have transacted message sends only. This has been done by implementing the TransactionInterceptor and a ResourceManager and associated classes. The ResourceManager keeps the map of Xid to transactions. This is reasonably similar to how it's done in Spy MQ, except I'm using an interceptor. It's not XA capable yet. Currently the ResourceManager is a Singleton - I'm conscious this probably needs to be scoped per Connection. I have some queries regarding which interceptors to put the logic in. For now I've used the TransactionInterceptor but I'm not sure whether I should put the logic in the session interceptor. There is a poissbility this needs to be refactored. I haven't implemented transacted acks yet. I have some questions about how to do this on previous threads in the forum. I've also added quite a few more tests to test the new functionality, and validated that the unit test suite runs fine still. The patch updates the following files: jms/src/etc/jms-aop.xml jms/src/main/org/jboss/jms/client/JBossConnectionFactory.java jms/src/main/org/jboss/jms/client/JBossConnection.java jms/src/main/org/jboss/jms/client/JBossConnectionMetaData.java jms/src/main/org/jboss/jms/client/JBossMessageProducer.java jms/src/main/org/jboss/jms/client/JBossSession.java jms/src/main/org/jboss/jms/client/container/ConnectionInterceptor.java jms/src/main/org/jboss/jms/client/container/InvokerInterceptor.java jms/src/main/org/jboss/jms/client/container/JMSInvocationHandler.java jms/src/main/org/jboss/jms/delegate/ConnectionDelegate.java jms/src/main/org/jboss/jms/delegate/ProducerDelegate.java jms/src/main/org/jboss/jms/delegate/ServerConnectionDelegate.java jms/src/main/org/jboss/jms/delegate/ServerProducerDelegate.java jms/src/main/org/jboss/jms/delegate/ServerSessionDelegate.java jms/src/main/org/jboss/jms/delegate/SessionDelegate.java jms/src/main/org/jboss/jms/server/container/InstanceInterceptor.java jms/src/main/org/jboss/jms/server/container/JMSAdvisor.java jms/tests/src/org/jboss/test/messaging/jms/ConnectionFactoryTest.java jms/tests/src/org/jboss/test/messaging/jms/ConnectionTest.java jms/tests/src/org/jboss/test/messaging/jms/MessageProducerTest.java And contains the following new files: jms/src/main/org/jboss/jms/client/container/ClosedInterceptor.java jms/src/main/org/jboss/jms/client/container/HierarchyInterceptor.java jms/src/main/org/jboss/jms/client/container/JMSMethodInvocation.java jms/src/main/org/jboss/jms/client/container/TransactionInterceptor.java jms/tests/src/org/jboss/test/messaging/jms/SessionTest.java jms/tests/src/org/jboss/test/messaging/jms/TransactedSessionTest.java I've uploaded the patch to JIRA task JBMESSAGING-34 since that's the best message. It also affects JBMESSAGING-37 (MesageConsumer) and JBMESSAGING-36 (MessageProducer), since some of the stuff is inextricably linked. Thanks -Tim View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875479#3875479 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875479 |
|
From: <tom...@jb...> - 2005-04-26 17:36:05
|
For the remoting build I have updated the component-info.xml to look like:
which allows both the jboss-remoting-tests.jar and jboss-remoting-loading-test.jar to be built as part of the new build. I assume that these jars are not part of the ../output/jbossremoting-1.0.1beta/lib directory because they are not included in the export tag, but are in the ../output/lib directory (which all good so far).
So my question is if I need to change the release.xml to be any different? Right now, it is:
I assume this is to declare the remoting component and the files related to the component (jboss-remoting.jar), which should be pulled from http://cruisecontrol.jboss.com/repository/remoting/5.0-SNAPSHOT/lib/. Then the includes tag decalres which component artifacts I actually want for my relase build?
So should I add the jboss-remoting-tests.jar and jboss-remoting-loading-test.jar as I did in the component-info.xml, but not add it in the includes?
Thanks.
-Tom
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875473#3875473
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875473
|
|
From: <ad...@jb...> - 2005-04-26 17:24:07
|
I'm confused again. We always seem to be on completely different wavelengths :-) 1) I already had a MAP in the original implementation, but changed it to Annotation since we agreed that all config will come from annotations (as opposed to ad hoc invocation payload) and this would make it easier for construct/configure from xml. In fact, there is an open issue on whether the MC should just use AOP's annotation metadata model. There is even a test in the jboss-aspects module using AbstractAnnotationMetaData: http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-aspects/src/tests/org/jboss/test/aspects/microcontainer/test/InterceptorTestCase.java?rev=1.1&view=markup Did you know that about FeatureMetaData or even the tasks I created after our Boston meetings? http://cvs.sourceforge.net/viewcvs.py/jboss/microkernel/src/main/org/jboss/beans/metadata/plugins/AbstractFeatureMetaData.java?r1=1.4&r2=1.5 http://jira.jboss.com/jira/browse/JBMICROCONT-18 2) It is too late to pass this in the join point constructor isn't it? I need to tell JBoss/AOP about the annotations to find out what they mean in terms of dependencies???? This cannot be done at the construction stage, it must be done during DESCRIBE. Otherwise, the MC/AOP integration serves no purpose. | | /** | * Get a constructor join point | * | * @param constructorInfo the constructor info | * @param metadata // THIS IS TOO LATE | * @return the constructor join point | * @throws JoinpointException when no such constructor | */ | ConstructorJoinpoint getConstructorJoinpoint(ConstructorInfo constructorInfo, Map metadata) throws JoinpointException; | Maybe you have simplied this or found a way around the problem? But it seems pretty fundamental to me? 3) The ClassAdapter should just be a bridge to JBoss/AOP or reflection model. That is its only purpose. i.e. which implementation should the MC use. To repeat the only reasons for the reflection model are: a) I need to be convinced that JBoss/AOP (really javassist) can be used in all environments b) AOP's ClassAdapter wasn't finished but I needed to work on other things If (a) can be satisfied, (i.e. in all circumstances no matter what the security/memory restrictions are JBoss/AOP/Javasssit can be used) then I don't have any problem with predecating JBoss/MC on JBoss/AOP and the need for an abstract integration "ClassAdapter" disappears. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875471#3875471 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875471 |
|
From: <sco...@jb...> - 2005-04-26 17:08:43
|
You are arguing for a transaction remoting module that combines the transaction and remoting codebases. That is fine. I'm sure the issue Francisco is having is reconcilling the tangled mess that currently exists as he is trying to prototype. Why not fix the dependencies/structure in the new build and then move the org.jboss.tm.remoting implementation and related to it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875468#3875468 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875468 |
|
From: <ad...@jb...> - 2005-04-26 16:43:04
|
Your problem is that org.jboss.tm.remoting implementation does not belong in the transaction manager module. The transaction manager module exists independently of remote access or its implementation details. You should not be making/fixing this integration at this level. In fact, the transaciton module needs to splitting up to separate the interfaces that define the integartion points and the real implementations. And the rest of JBoss should just use the interfaces/not the implementation. I remember discussing this before in an earlier thread???? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875461#3875461 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875461 |
|
From: <sco...@jb...> - 2005-04-26 15:46:46
|
Then you have not understood the BaseCertLoginModule/JaasSecurityDomain. It can have a distinct trust store for validation of the client cert at the transport level and another for validation of the client cert. Reread the BaseCertLoginModule as of the 4.0.2 release there is also a pluggable certificate validator interface that can perform the client cert check anyway it wants. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875454#3875454 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875454 |
1965 messages has been excluded from this view by a project administrator.
