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: wobbet <nu...@jb...> - 2005-05-12 22:38:15
|
W00T! I added -XX:MaxPermSize=128m -Xmx512m To the JVM start arguments in the debugger and it worked just fine! I went into telnet on port 110 to retrieve the email that I had created and the X-SpamScore header was displayed with the same value that I saw presented during the debug session. Life is good... Some config questions though... First - I have my listener added in as a depends and as a listener in the org.jboss.mail.MailListenerChainService xmbean declaration in the jboss-service.xml file. It appears that my listener is being invoked on the send instead of the receive but I wasn't paying enough attention to be sure. Is that really what I'm seeing? Is that important right now? If it is on the send and it is important that I do it on the recieve, how do I config a listener chain for receive? Second - jASEN has two different directories of data that it relies on - one for configuration information and one is the "database" it uses to determine scoring. I need to do a bit more research but from what I currently read the configuration can be read-only (if you never want to change the config of course) but the "database" should be read-write to allow training. Where can/should these directories go for a production style deployment? Third - Once I get this to the point where I can reliably deploy on a machine other than my dev machine I'll work on some jUnit tests. What sort of tests would be appropriate? I'm thinking that a collection of tests each with different email content that gives reasonable scores would be good. Should I add tests directly to my listener or should I add them in the listener chain tests (is there such a beast?) or should I do both or something completely different? Finally - Someone (mikezzz???) suggested that I write up a page on how to write a listener along with info on getting stuff up and running in Eclipse. Do I need special permissions to edit Wiki pages and if so should I just submit something coherent to Mike or Andrew or ??? Many thanks! rjsjr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877563#3877563 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877563 |
From: <ben...@jb...> - 2005-05-12 21:56:41
|
This topic belongs to user forum. I am moving it over there. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877555#3877555 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877555 |
From: wobbet <nu...@jb...> - 2005-05-12 21:47:52
|
Annoyance #1 - toString() does NOT return a MIME string, it returns the simple object classname and instance id. What I really wanted is getRawStream() which appears to be working... Status update 1 - Created the mail listener as a POJO and created an xbean descriptor for it (can I assume that the xbean/POJO combo is invoking AOP to make it behave as a real MBean?). 2 - Added the listener to the chain using the entries in jboss-service.xml 3 - launch debug within jboss ide and use telnet to invoke the mail 4 - hit the breakpoint in the listener 5 - run out of memory when initializing the jasen confg :( The exception says I'm out of Java heap space. Is this an issue w/ my debug config not allocating enough RAM to the JVM or is this an issue with not having enough allocated to Eclipse or is this an issue w/ jASEN just eating too much and needing to be put on a diet? Yeah, yeah, yeah - you probably don't have enough info to tell me but I know that you've used the JBoss/Eclipse IDE and debugged within it so if there is some magic there then I know that you can help me with that. Thanks! rjsjr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877547#3877547 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877547 |
From: nthx <nu...@jb...> - 2005-05-12 21:47:09
|
"bil...@jb..." wrote : execution and set/get do not make sense with within as their purpose | is to totally wrap EVERY invocation. | | within and withcode only make sense with call. I guess a callfield is necessary. I'll add that to the TODO. | | Bill Hi there! I came to that problem tonight again.. Actually, it does make sense. One can has "execution(* class->method(..)) AND !within(ExcludedClass)" in AspectJ. It makes sense. I'd like to intercept any execution of method "method", but not in the class "ExcludedClass". How would that be with JBAOP? Tomasz Nazar View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877546#3877546 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877546 |
From: wobbet <nu...@jb...> - 2005-05-12 21:42:03
|
On the Win2K box it is running as a service and is using the machine account. I *assume* that means it can run as admin. On my XP Pro box my user account is (and always has been) an admin, I run JBoss within a DOS box. It is working now after my latest build for some screwy reason... rjsjr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877544#3877544 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877544 |
From: <ad...@jb...> - 2005-05-12 21:26:23
|
Yes, but the problem is also with processing the attributes. <key class="java.lang.Integer">7</key> will eventually lead to map.put(new StringValueMetaData("java.lang.Integer", "7"), ...) whereas <key><collection/></key> leads to map.put(new CollectionValueMetaData(), ...) The new AbstractValueMetaData(new StringValueMetaData())) serves two purposes 1) The AbstractValueMetaData is really just a holder for the polymorphic object 2) I have somewhere to store the attributes if they are present, although they only apply if there is a direct xsd:string element. The problem I think is the ordering, which means I have to put something in place to meet all possible later outcomes: key -> AbstractValueMetaData attributes -> StringValueMetaData valueGroup -> It is only here that I know what is really going on This also repeats for the "value" part of the map element. Maybe I should be looking at richer holder object that does things a bit more lazily? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877542#3877542 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877542 |
From: <tom...@jb...> - 2005-05-12 19:56:16
|
Not sure what you mean by "take care of the Socket connection state", so you will have to explain that one a little more for me. As for the ability to view the socket connection state via JMX, this is not supported. Only that the invoker has been started or not. If would like to see this added, submit a feature request in Jira under the JBoss Remoting project (http://jira.jboss.com/jira/secure/BrowseProject.jspa?id=10031) and add a use case for it. Thanks. -Tom View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877533#3877533 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877533 |
From: <tom...@jb...> - 2005-05-12 19:52:10
|
This is now in jboss-head. It is under jbossas/remoting directory and is found in jbossas-remoting.jar (which is also part of jboss server distro under all/lib and default/lib). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877532#3877532 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877532 |
From: janole <nu...@jb...> - 2005-05-12 19:41:43
|
Thanks, I have done a clean checkout to an empty catalog (at least I thought so) Size of my index.jsp is 16837 bytes, dated 2005.04.26, 21.01 (decoration.jsp in same catalog has date 2005.04.21) jan ole View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877530#3877530 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877530 |
From: mholzner <nu...@jb...> - 2005-05-12 17:36:37
|
hmm, you must have an older version of the index.jsp Perhaps something in the deploy cache ? You are correct: the PageHolder has moved recently, but all files have been corrected to reflect that change. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877516#3877516 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877516 |
From: <sco...@jb...> - 2005-05-12 17:07:07
|
That's a good question, and this gets into the subject of different levels of build artifacts. The only context I have looked at a component element is for this simple thirdparty structure creation from the repository. What your talking about is a much higher level artifact in the top level build structure. My mind cannot make a jump from a simple hibernate.jar depends on cglib.jar to the fact that there is a deploy/jboss-hibernate.deployer with these jars inside. The cglib.jar may need to be in the deployer, or it may need to be in the server lib directory to be shared across all contexts. This is at least two level removed from the simple dependency. The first level is where the jboss-hibernate.deployer artifact is defined. The next level is how this artifact integrates into the jbossas release structure. If we are going to get to the level of generating an IzPack build target for jbossas based on its component dependencies, composition of components as well as mapping of their artifacts into containing components needs to be figured out. I'm not there yet. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877510#3877510 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877510 |
From: <rya...@jb...> - 2005-05-12 16:39:03
|
"sco...@jb..." wrote : As was mentioned in this post which spawned the JBBUILD-72 issue, its not practical for the component user to have to know the dependencies of the component. Case 1, hibernate depends on cglib and asm, neither of which are used anywhere else in jbossas. In creating the top level build I only know I need hibernate 3.0.3. The component-info.xml for hibernate 3.0.3 needs to tell the synchronize process that cglib and asm are also needed. | Ok, so if we want this behavior to apply to toplevel builds, the only problem I see is that the toplevel build still has the responsibility to define *where* to put cglib and asm in the release. I guess we could just decide that all transitive dependencies are placed in the same directory as the direct dependency? E.g., if hibernate goes in server/all/lib, so do asm and cglib. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877503#3877503 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877503 |
From: fernir <nu...@jb...> - 2005-05-12 15:34:51
|
There is no public draft of WSRP 2.0 specification. You will have to join WSRP TC group. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877493#3877493 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877493 |
From: calin.pavel <nu...@jb...> - 2005-05-12 14:33:45
|
During the development time I want to use the unified classloading mechanism and I have 2 EAR's, lets say EAR_A and EAR_B. The EAR_A contains some ejbs that are using some services (ejbs) from EAR_B. If I try to start the JBoss (4.0.0), deploy EAR_B and EAR_A everything is ok. But if I try to start JBoss with those two EARs already deployed, the deployment mechanism tries to deploy first (suppose alphabetically) EAR_A and this can not be performed because EAR_B is not present. Do you have any idea what can be done in such situations ? Is it there any possibility to change the order of deployment to a custom one? Thank you, Calin View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877480#3877480 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877480 |
From: mafor <nu...@jb...> - 2005-05-12 14:20:16
|
Currently Object*Streams are wrapped around the raw socket streams since the ObjectOutputStream needs to be reset between ping-packets. To be able to forward the raw socket streams directly to the marshallers (needed if you want to implement a proprietary protocol) one could implement a new subclassed OutputStream that wraps the ObjectOutputStream if needed. In this way the ObjectOutputStream is only used when needed and has the least impact on the architecture. See code below. This class is then used within ServerThread.java and SocketClientInvoker.java instead of the ObjectOutputStream. The marshallers has several options, either use the ResetOutputStream directly or ask it to generate or use an ObjectOutputStream. When a reset is being issued it is propagated to the ObjectOutputStream if available. The ObjectInputStream doesn't need to be reset (it is automatically reset from the stream) so it is simply removed. I have run some tests and it seems to work. Do you think this is possible way to go? package org.jboss.remoting; | | import java.io.IOException; | import java.io.ObjectOutputStream; | import java.io.OutputStream; | | public class ResetOutputStream extends OutputStream | { | ObjectOutputStream oout ; | OutputStream out ; | | public ResetOutputStream(OutputStream out) | { | this.out = out ; | } | | public void write(int value) throws IOException | { | out.write(value) ; | out.flush() ; | } | | public ObjectOutputStream getObjectStream() throws IOException | { | if( oout == null ) | oout = new ObjectOutputStream(out) ; | | return oout ; | } | | public void setObjectStream(ObjectOutputStream oout) | { | this.oout = oout ; | } | | public void reset() throws IOException | { | if( oout != null ) | oout.reset() ; | } | } View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877472#3877472 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877472 |
From: <ale...@jb...> - 2005-05-12 13:09:23
|
"ad...@jb..." wrote : Essentially, the problem is that to get the polymorphism to work, | I have to introduce a type binding, in this case | key -> valueType | value -> valueType | where valueType can be collection/array/list/ANY/etc. | | But this then requires an extra object to be constructed to model the polymorphic behaviour: | | | | // value binding | | TypeBinding valueType = schemaBinding.getType(valueTypeQName); | | | | configureValueBindings(valueType); // <------ subelements | | | | valueType.setHandler(new DefaultElementHandler() | | { | | public Object startElement(Object parent, QName name, TypeBinding type) | | { | | return new AbstractValueMetaData(new StringValueMetaData()); | | } | | etc. | | | | Then later I have to unwrap the extra AbstractValueMetaData | | | AbstractMapMetaData map = (AbstractMapMetaData) parent; | | MapEntry entry = (MapEntry) child; | | AbstractValueMetaData entryKey = (AbstractValueMetaData) entry.key; | | if (entryKey == null) | | throw new IllegalArgumentException("No key in map entry"); | | AbstractValueMetaData entryValue = (AbstractValueMetaData) entry.value; | | if (entryValue == null) | | throw new IllegalArgumentException("No value in map entry"); | | map.put(entryKey.getValue(), entryValue.getValue()); | | You want to get rid of constructing an instance of AbstractValueMetaData, right? I think, you could just use the DefaultElementHandler as is, w/o overwritting the startElement. Which will just propagate the MapEntry further and you will be able to add the actual key and value to it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877461#3877461 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877461 |
From: <ale...@jb...> - 2005-05-12 12:42:33
|
"sco...@jb..." wrote : I don't see a problem with needing to create holder objects. The main advantage is that they give you a type explicit representation of the stack as opposed to having to know the types and order of the stack. Ok, thanks for feedback. "sco...@jb..." wrote : I think the general extension to jaxb that we need is the notion of a holder object that is a java bean which can be constructed via standard jaxb rules or customizations + a mapping of that holder into the actual object. The mapping could be specified via simple transform/factory interface. I actually have this general holder. There are some tests for classes that don't have no-arg ctors. I find out that at runtime and collect children. When element is parsed I am trying to find a constructor that would take all the children (the order is the order of the elements in the XML content). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877457#3877457 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877457 |
From: <ale...@jb...> - 2005-05-12 12:33:58
|
ObjectModelFactory API is stable currently. I don't plan to change this API in the near future. SchemaBinding is under development. You can use it but I might need to update your code after my refactorings. I would say use whatever is easier for you for now. We will refactor it anyway in the future. About namespaces, please, clarify. Namespaces have been there since day one. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877455#3877455 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877455 |
From: janole <nu...@jb...> - 2005-05-12 11:08:31
|
clean checkout from cvs, build ok, but when i access url http://localhost:1080/portal/auth/index.html?ctrl:id=page.default.admin exception is thrown java.lang.NoClassDefFoundError: org/jboss/portal/core/theme/PageHolder at org.apache.jsp.nodesk.index_jsp._jspService(index_jsp.java:76) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.portal.server.theme.LayoutDispatcher.execute(LayoutDispatcher.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.portal.server.servlet.CommandFilter.doFilter(CommandFilter.java:54) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510) at org.jboss.portal.server.theme.LayoutDispatcher.include(LayoutDispatcher.java:84) at org.jboss.portal.core.servlet.CoreServlet.render(CoreServlet.java:239) at org.jboss.portal.server.servlet.AbstractMainServlet.invoke(AbstractMainServlet.java:81) at org.jboss.portal.server.servlet.AbstractMainServlet.doGet(AbstractMainServlet.java:71) at javax.servlet.http.HttpServlet.service(HttpServlet.java:697) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.portal.core.servlet.TransactionFilter$1.run(TransactionFilter.java:79) at org.jboss.portal.common.transaction.Transactions.requiresNew(Transactions.java:149) at org.jboss.portal.core.servlet.TransactionFilter.doFilter(TransactionFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:540) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:54) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:595) When I look into the source it seems to me that org/jboss/portal/core/theme/PageHolder.java has moved to org/jboss/portal/server/theme and that theme code has been refactored since my last checkout (20040419). Somthing I have missed, or is it still some references to the old code? jan ole View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877452#3877452 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877452 |
From: <iv...@jb...> - 2005-05-12 10:51:17
|
Makes sense. It is consistent with the way we populate in the UCL3 repository information about all packages that a registered classloader recognizes at deployment time. As additional minor optimization, per compressed archive, the dependency table can be written to a cash file on first startup and loaded consequently. Ivelin View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877451#3877451 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877451 |
From: <sac...@jb...> - 2005-05-12 10:20:13
|
There was discussion going on (between Adrian and Bill) about the excessive time it would take if we wanted the MC to be fully aware of all dependencies before actually loading classes. The idea was, for the MC, to be able to read dependencies from a class file before actually loading the class through a CL, satisfy these dependencies and the load the class. It looks like loading these dependencies on a class by class basis (at the time you load the class), takes a lot of time. Hence, I wanted to test how much time it would take if, instead of loading that information at class-load time, we would load it at deployment-time, when a new xAR gets deployed, for ALL classes in that JAR. The code below just does this: - it list a folder - read all JARs in that folder - for each JAR read all *.class files - for each class file analyse its bytecode (WITHOUT LOADING THE CLASS) - read class, method and field annotations - populate a repository which, for each class name, store the list of related annotations that are required by that class. On my laptop, loading the JBoss 3.2.x lib folder (~9Mo of JARs) takes 2.8 seconds. Now, this can be optimized as lots of JARs are simply "dumb code" (with no annotations) such as parsers, JSR-77 API, etc. removing a few of these jars bring the analysis time below 2 seconds. Hence, instead of analysing the dependencies at CLASS-LOAD-TIME, one-by-one, why not do it at DEPLOYMENT-TIME, for all classes in the xAR, and store that dependency data structure in the related xAR DeploymentInformation. Hence, once the classloader would have to actually load a specific class, it would not have to analyse the bytecode at that time but instead rely on the pre-populated dependency data structure that had been built at deployment time. FYI, code uses Javassist low-level API ro read class bytecode: | | import javassist.bytecode.*; | | import java.util.jar.*; | import java.util.zip.ZipEntry; | import java.util.Iterator; | import java.util.List; | import java.util.ArrayList; | import java.io.DataInputStream; | import java.io.FileFilter; | import java.io.File; | import java.io.BufferedInputStream; | | public class ReadClass { | | ArrayList db = new ArrayList(6000); | | public static void main (String[] args) throws Exception | { | ReadClass self = new ReadClass (); | self.doJob (); | } | | public void doJob () throws Exception | { | File file = new File ("P:\\CVS_HOME\\jboss-3.2\\build\\output\\jboss-3.2.6RC2\\server\\default\\lib"); // replace with your directory here | File[] files = file.listFiles(new FileFilter() | { | public boolean accept (File f) | { | return f.isFile() && f.getName().endsWith(".jar"); | } | } | ); | | long start = System.currentTimeMillis(); | | for (int i=0; i<files.length; i++) | { | processFile(files \[i\] ); | } | | System.out.println ("Total time: " + (System.currentTimeMillis() - start)); | System.out.println ("Total classes: " + db.size()); | | | | } | | public void processFile (File fileToProcess) | throws Exception | { | DataInputStream in = null; | | JarFile file = new JarFile (fileToProcess); | java.util.Enumeration entries = file.entries(); | | while (entries.hasMoreElements()) | { | ZipEntry entry = (ZipEntry) entries.nextElement(); | if (entry.getName().endsWith(".class")) | { | ArrayList annotations = new ArrayList(); | | in = new DataInputStream (new BufferedInputStream (file.getInputStream(entry))); | ClassFile cf = new ClassFile (in); | | // Classes attributes | // | extractAnnotations (cf.getAttributes(), annotations); | | // Methods attributes | // | Iterator methods = cf.getMethods().iterator (); | while (methods.hasNext()) | { | MethodInfo method = (MethodInfo)methods.next(); | extractAnnotations( method.getAttributes(), annotations); | } | | // Fields attributes | // | Iterator fields = cf.getFields().iterator (); | while (fields.hasNext()) | { | FieldInfo field = (FieldInfo)fields.next(); | extractAnnotations( field.getAttributes(), annotations); | } | | // Add annotations to shared structure | // | db.add(new ClassAnnotation (cf.getName(), annotations)); | } | } | | } | | public void extractAnnotations (List attrs, ArrayList store) | { | Iterator attributes = attrs.iterator(); | while (attributes.hasNext()) | { | AttributeInfo attr = (AttributeInfo)attributes.next(); | if (attr instanceof AnnotationsAttribute) | { | store.addAll(java.util.Arrays.asList( ((AnnotationsAttribute)attr).getAnnotations())); | } | } | | } | | public class ClassAnnotation | { | String name; | ArrayList annotations; | | // store which annotations are being used by a given class | public ClassAnnotation (String name, ArrayList annotations) | { | this.name = name; | this.annotations = annotations; | } | } | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877448#3877448 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877448 |
From: drzewo <nu...@jb...> - 2005-05-12 09:48:22
|
"radhikamehta" wrote : hi! I have a standalone java program which tries to lookup a sessionbean deployed in jboss3.2.0 in a remote machine. | I am using cluster configuration. | My java code snippet is: | | Properties p = new Properties(); | p.put (Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory | "); | p.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces"); | p.put(Context.PROVIDER_URL, "xxx.xxx.xxx.xxx:1100"); // HA-JNDI port. | Context ctx = new javax.naming.InitialContext(p); | Object ref = ctx.lookup("abc"); | | My problem is that it gives a communication exception during lookup. | The exception is:: | | | javax.naming.CommunicationException. Root exception is java.rmi.RemoteException | : Service unavailable. | at org.jboss.ha.framework.interfaces.HARMIClient.invokeRemote(HARMIClien | t.java:165) | at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java | :203) | at $Proxy0.lookup(Unknown Source) | at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:492) | at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:471) | at javax.naming.InitialContext.lookup(InitialContext.java:347) | | Darn, I am getting the very same behaviour. Either I am doing something wrong or the nasty bug hasn't been fixed for quite some time. This happens in jboss 4.0.2. Here is a short description of my config. As I am trying to configure HA JMS with farming I took the following steps: - I bound several IP adresses to one physical interface, namely 10.0.0.1 and 10.0.0.2 - copied the "all" config to "m1" and striped it a bit of unused services. It launches with no problems when invoked with a command "run -c m1 -Djboss.bind.address=10.0.0.1 -Djboss.partition.name=customCluster". JMS is deployed as a singleton. - copied the "m1" to "m2" and launched with a command "run -c m2 -Djboss.bind.address=10.0.0.2 -Djboss.partition.name=customCluster"; m2 joins the cluster - I have written, compiled, configured and packaged a simple MDB. I deployed a jar to the farm directory of m1. The bean gets deployed on both m1 and m2 and both bind to the defined queue. I had to slightly modify hajndi-jms-ds.xml, so that the queue used by the MDB was looked up in the HAJNDI I have set java.naming.provider.url=10.0.0.1:1100 and java.naming.provider.url=10.0.0.2:1100 for m1 and m2 respectively. - Now the client part. It is intended to send messages to the queue but fails during lookup of the queue and the connectionfactory (regardless of which comes first) with the following "javax.naming.CommunicationException. Root exception is java.rmi.RemoteException: Service unavailable" I cannot post the whole stack at the moment, but it looks very similar (the same method invocation path, line numbers might differ, as I use the latest jboss 4.0.2) Now the funny part. When I lunch a single server "m1" or "m2" without specifying jboss.bind.address, the ha-jndi seems to bind to 0.0.0.0:1100 instead of ${jboss.bind.address):1100, and when I changed the client's java.naming.provider.url to localhost:1100, it runs like a charm! I am doing something wrong, arent I? Any ideas, anybody? cheers, /dd View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877446#3877446 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877446 |
From: <kab...@jb...> - 2005-05-12 09:08:28
|
1) Not unless it contains synchronised blocks of code 2) For SLSB there should not be any point in scoping per instance, PER_CLASS can be used to associate info with a class View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877440#3877440 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877440 |
From: mikezzz <nu...@jb...> - 2005-05-12 07:55:14
|
Is the user account, you are running jboss as, an adminstrator account? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877435#3877435 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877435 |
From: twundke <nu...@jb...> - 2005-05-12 02:26:17
|
Thanks Scott. I'm happy to help with the implementation of the fix if needed. Tim. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877412#3877412 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877412 |