jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of Mail Services] - Re: More jASEN

[mikezzz <nu...@jb...>]

This exception normally means that it can't find the {Class}.hbm.xml files.  Make sure there is a mail.har archive inside the mail.ear and that it contains org/jboss/mail/store/paged/Page.hbm.xml and org/jboss/mail/store/paged/Blob.hbm.xml.

Mike.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878050#3878050

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878050

[Jboss-dev-forums] [Design of Mail Services] - Re: More jASEN

[wobbet <nu...@jb...>]

Now that I've recovered from my temporary insanity...

I was having trouble with deploying a build when I discovered that there are two sections of the build.xml in which I need to specify libs and the config data - one in the jar task for mail.sar and the other in the copy-to sub-task of the mkunwrapped task for creating dev-deploy. So that leads me to my question of...

Why does the mkunwrapped task use its own list of files to copy rather than
a) Building all of the binary distributables and then exploding them to the dev-deploy directory or
b) Using one or more Ant filesets defined outside of the tasks to be referenced inside of the task?

I understand that item (a) may not be the desired way to go because you then add a dependency. So why not item (b)? Is there a technical reason that it should not be done?

If there is no technical reason and there are no objections then I will move the build to use common filesets to simplify maintenance. If there are objections, let me know what they are and I will either work around them or not do it.

The second issue I ran into is that when running the app in the Eclipse/JBoss IDE debugger everything worked great. But when I deployed (after getting the data files into the .sar appropriately) I got exceptions saying that my mail could not be persisted because there was a problem with Hibernate. I've never used Hibernate (I will be happy to make jASEN's map thingy be my first implementation of it after I get the base deploy working) so I don't know if I'm simply missing something off of my classpath or what. The exception I received is...


  | 10:07:56,647 INFO  [Mail] all headers after loading: MailHeadersImpl (6): [hdr(R
  | eceived = 'Received: from localhost.localdomain.com (localhost 127.0.0.1) by loc
  | alhost.localdomain.com/JBossMail 1.0M3 (127.0.0.1)
  |         with SMTP id 1116342476647559.2326712449285; Tue, 17 May 2005 10:07:56 -
  | 0500 (CDT)'), hdr(To = 'To: <aco...@lo...>'), hdr(From = '
  | From: <aco...@lo...>'), hdr(Subject = 'Subject: error'), h
  | dr(Content-Type = 'Content-Type: text/plain; charset=us-ascii'), hdr(Content-Tra
  | nsfer-Encoding = 'Content-Transfer-Encoding: 8bit')]
  | 10:07:56,717 DEBUG [PagedStore] Creating Store Item
  | 10:07:56,737 DEBUG [SessionFactoryObjectFactory] JNDI lookup: jbossmail.Hibernat
  | eSessionFactory
  | 10:07:56,737 DEBUG [SessionFactoryObjectFactory] lookup: uid=8a8a82eb03eb303c010
  | 3eb303d680000
  | 10:07:56,918 DEBUG [SessionImpl] opened session
  | 10:07:56,928 DEBUG [JTATransaction] Looking for UserTransaction under: UserTrans
  | action
  | 10:07:56,928 DEBUG [JTATransaction] Obtained UserTransaction
  | 10:07:56,928 DEBUG [JTATransaction] beginning new transaction
  | 10:07:56,928 DEBUG [HibernateUtil] Begin Transaction: createStoreItem:701837
  | 10:07:56,998 DEBUG [PagedStore] Rollback Transaction: 701837
  | 10:07:56,998 DEBUG [JTATransaction] rollback
  | 10:07:56,998 DEBUG [SessionImpl] transaction completion
  | 10:07:57,008 ERROR [PagedStore] Failed to create store item. No persister for: o
  | rg.jboss.mail.store.paged.Blob
  | 10:07:57,008 DEBUG [SessionImpl] closing session
  | 10:07:57,008 ERROR [Mail] org.jboss.mail.store.StoreException: net.sf.hibernate.
  | MappingException: No persister for: org.jboss.mail.store.paged.Blob
  | org.jboss.mail.store.StoreException: net.sf.hibernate.MappingException: No persi
  | ster for: org.jboss.mail.store.paged.Blob
  |         at org.jboss.mail.store.paged.PagedStore.createStoreItem(PagedStore.java
  | :477)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  |         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
  | java:39)
  |         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
  | sorImpl.java:25)
  |         at java.lang.reflect.Method.invoke(Method.java:585)
  |         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
  | er.java:144)
  |         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
  |         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
  |         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
  | java:249)
  |         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
  |         at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvoc
  | ationHandler.java:201)
  |         at $Proxy84.createStoreItem(Unknown Source)
  |         at org.jboss.mail.message.StoredMailBody.newInstance(StoredMailBody.java
  | :60)
  |         at org.jboss.mail.message.MailBodyManager.createMailBody(MailBodyManager
  | .java:38)
  |         at org.jboss.mail.message.MailBodyManager.createMailBody(MailBodyManager
  | .java:83)


Many thanks!

rjsjr

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878039#3878039

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878039

[Jboss-dev-forums] [Design of JBoss Portal] - Re: JBoss Portal Webinar Next Week

[<dam...@jb...>]

I can't wait.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878037#3878037

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878037

[Jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Re: Object*Stream wrapping of raw socket streams

[mafor <nu...@jb...>]

There is another way to solve but it requires some refactoring to move the ping handling to intermediate filter streams. In this way, even if the marshallers wraps the stream with an Object*Stream, the intermediate streams will manage the pings.

Stream hierarchy:

   Raw*Stream -> Buffered*Stream -> Ping*Stream (-> Object*Stream)

The PingOutputStream wraps the raw socket output stream and adds a thin layer of ping management. The PingOutputStream contains a timer that generates a ping at predefined intervals. The ping timer is reset every time some real data is written so a ping is only generated when needed. The logic for this is located within the write(int) method and is synchronized so no other data can be written during pings. Immediately after sending the ping the stream will try to read the responding pong packet.

A corresponding PongInputStream similiarly wraps the raw socket input stream and adds a thin layer looking for the arrival of a ping packets. If a ping packet is received it immediately replies by sending back a pong packet. Otherwise the data is just forwarded as usual.

Since the ping/pong packets are totally managed within the intermediate filter streams there is no need to issue a reset on the Object*Streams used by the marshallers.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878035#3878035

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878035

[Jboss-dev-forums] [Design of JBoss Portal] - JBoss Portal Webinar Next Week

[<roy...@jb...>]

We will be holding a webinar next week covering some of the features on JBoss Portal and a short demo of some items.

You can register for it here: http://www.jboss.org/index.html?module=webex&title=JBoss%20Portal%202.0&speaker1=Julien%20Viet&date=May%2025,%202005&confid=756214655

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878034#3878034

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878034

[Jboss-dev-forums] [Design of Mail Services] - Re: More jASEN

[mikezzz <nu...@jb...>]

It would probably need to go at the base level of SAR.

It would require that the user redeploy the application to update the file.  However I believe that this needs to happen whenever the configuration changes also so not such a big deal.

It kinda depends how we are treating the dictionaries.  If you are treating them as configuration then inside the SAR is reasonably valid place for it to go.  If the dictionaries are considered as application data then the database is a better place (this is my preference).

Mike.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878031#3878031

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878031

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Theme API Doc added

[mholzner <nu...@jb...>]

anonymous wrote : The divRenderer seems to be a reference to a particular rendererSet. By default, the value for the rendererSet is reference is emptyRenderer. My question is where are those values (divRenderer, emptyRenderer, etc.) defined. 

The named render sets are defined in (portal-core.war)/WEB-INF/layouts/portal-renderSet.xml 

The named strategies are defined in 
(portal-core.war)/WEB-INF/layouts/portal-strategies.xml 

I put the war in brackets since you could add your own implementations into any of the WARs you deploy to the portal, as long as they are in the same location (WEB-INF/themes) with the same name , and conform to the DTDs defined (see /core/resources/dtd/portal_renderSet_2_0.dtd and portal_strategies_2_0.dtd)

Note that those render sets are still experimental. We're still trying to get more feedback from web developers about the right level of separation between the render set and the css in the theme. If we can get to a 'standard' set of tags and selectors produced by the render set, we could have 'standardised' themes (think Firefox skins and the likes) ; in other words: if we have a well known set of selectors and tags, and themes that comply with those, we could have exchangable themes.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878029#3878029

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878029

[Jboss-dev-forums] [Design of Mail Services] - Re: More jASEN

[wobbet <nu...@jb...>]

Okay, okay, okay I'll say it so you don't have to.

I'm being an idiot. The data would go directly into the .sar and not worry about META-INF/lib...

Sigh...

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878026#3878026

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878026

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Portlet intercommunication

[dajevtic <nu...@jb...>]

Ok, will do. For now I am posting the two portlets I wrote yesterday, in order to check TreeCache functionality for inter portlet communication. It is quick and dirty, so please ignore the fact that this is not production ready code. Maybe it will give some insight to others, who are thinking about implementing interportlet communication. Any constructive criticism is more than welcome. I want to use a Wrapper class so that the portlets themselves do not have to access (and configure connection) to the Cache itself.

DoCachePortlet Source code:

import java.io.IOException;
import java.io.PrintWriter;
import java.security.Principal;
import java.util.Map;

import javax.management.MBeanServer;
import javax.management.MalformedObjectNameException;
import javax.portlet.ActionRequest;
import javax.portlet.ActionResponse;
import javax.portlet.GenericPortlet;
import javax.portlet.PortletConfig;
import javax.portlet.PortletException;
import javax.portlet.PortletSecurityException;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;

import org.jboss.cache.CacheException;
import org.jboss.cache.TreeCacheMBean;
import org.jboss.mx.util.MBeanProxyExt;
import org.jboss.mx.util.MBeanServerLocator;

/**
* XDoclet generated portlet description
*
* @portlet.portlet
* description="This portlet displays a form with 3 text fields an a submit button."
* display-name="DoCachePortlet"
* expiration-cache="0"
* name="DoCachePortlet"
* 
* @portlet.portlet-init-param
* name="CacheService"
* value="jboss.cache:service=TreeCache"
*
* @portlet.portlet-info
* title="CacheInputForm"
*
* @portlet.supports
* mime-type="text/html"
* modes="VIEW"
*
* @author Danijel Jevtic <danijel_point_jevtic_at_livemediagroup_dot_de>
* @version 1.0
*/
public class DoCachePortlet extends GenericPortlet {

    private String cacheService;
    private MBeanServer server;
    private TreeCacheMBean cache;

    private static final String CONTENT_TYPE = "text/html";
    
    public void init(PortletConfig config) throws PortletException {
        super.init(config);
        // cacheService e.g. 'jboss.cache:service=TreeCache'
        cacheService = getInitParameter("CacheService");
        if (cacheService == null) {
            throw new PortletException("No cache defined");
        }
        // locate MBeanServer
        server = MBeanServerLocator.locate();
        try {
            // get the tree cache
            cache=(TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, cacheService, server);
        } catch (MalformedObjectNameException mone) {
            throw new PortletException(mone);
        }
    }
    
    public void doView(RenderRequest request, RenderResponse response) throws PortletException, PortletSecurityException, IOException {
        response.setContentType(CONTENT_TYPE);
        PrintWriter out = response.getWriter();
        out.print("<form name=\"somename\" method=\"post\" action=\"" + response.createActionURL() + "\">");
        out.print("<input type=\"text\" name=\"input1\"/>");
        out.print("<input type=\"text\" name=\"input2\"/>");
        out.print("<input type=\"text\" name=\"input3\"/>");
        out.print("<input type=\"submit\"/>");
        out.print("");
    }
    
    public void processAction(ActionRequest request, ActionResponse response) throws PortletException, PortletSecurityException, IOException {
        String tree;
        Principal user = request.getUserPrincipal();
        if (user == null) {
            tree = request.getPortletSession().getId() + "/" + getPortletName();
        } else {
            tree = user.getName() + "/" + getPortletName();
        }
        try {
            writeToCache(tree, request.getParameterMap());
        } catch (CacheException ce) {
            throw new PortletException(ce);
        }
    }

    private void clearCache(String id) throws CacheException {
        cache.remove("/" + id);
    }
    
    private void writeToCache(String id, Map parameterMap) throws CacheException {
        clearCache(id);
        cache.put("/" + id, parameterMap);
    }
    
}


DoReceivePortlet source code:
import java.io.IOException;
import java.io.PrintWriter;
import java.security.Principal;
import java.util.Enumeration;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Set;

import javax.management.MBeanServer;
import javax.management.MalformedObjectNameException;
import javax.portlet.GenericPortlet;
import javax.portlet.PortletConfig;
import javax.portlet.PortletException;
import javax.portlet.PortletSecurityException;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;

import org.jboss.cache.CacheException;
import org.jboss.cache.TreeCacheMBean;
import org.jboss.mx.util.MBeanProxyExt;
import org.jboss.mx.util.MBeanServerLocator;

/**
* XDoclet generated portlet description
*
* @portlet.portlet
* description="This portlet displays the form previous form posts."
* display-name="DoReceivePortlet"
* expiration-cache="0"
* name="DoReceivePortlet"
* 
* @portlet.portlet-init-param
* name="CacheService"
* value="jboss.cache:service=TreeCache"
*
* @portlet.portlet-info
* title="CacheDisplay"
*
* @portlet.supports
* mime-type="text/html"
* modes="VIEW"
*
* @author Danijel Jevtic <danijel_point_jevtic_at_livemediagroup_dot_de>
* @version 1.0
*/
public class DoReceivePortlet extends GenericPortlet {

    private static final String CONTENT_TYPE = "text/html";

    // the name of the portlet which posted the form values
    private static final String TRUSTED_PORTLET_NAME = "DoCachePortlet";

    private String cacheService;
    private MBeanServer server;
    private TreeCacheMBean cache;

    public void init(PortletConfig config) throws PortletException {
        super.init(config);
        // cacheService e.g. 'jboss.cache:service=TreeCache'
        cacheService = getInitParameter("CacheService");
        if (cacheService == null) {
            throw new PortletException("No cache defined");
        }
        // locate MBeanServer
        server = MBeanServerLocator.locate();
        try {
            // get the tree cache
            cache=(TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, cacheService, server);
        } catch (MalformedObjectNameException mone) {
            throw new PortletException(mone);
        }
    }
    
    public void doView(RenderRequest request, RenderResponse response) throws PortletException, PortletSecurityException, IOException {
        String sessionId = request.getPortletSession().getId();
        response.setContentType(CONTENT_TYPE);
        PrintWriter out = response.getWriter();
        Hashtable parameters;
        
        String tree;
        Principal user = request.getUserPrincipal();
        if (user == null) {
            out.print("Using your session ID for parameter storage");
            tree = request.getPortletSession().getId() + "/" + TRUSTED_PORTLET_NAME;
        } else {
            out.print("Using your user name for parameter storage");
            tree = user.getName() + "/" + TRUSTED_PORTLET_NAME;
        }
        try {
            parameters = getParameters(tree);
        } catch (CacheException ce) {
            throw new PortletException(ce);
        }
        
        if (!parameters.isEmpty()) {
            out.print("You entered the following form parameters:");
            Enumeration keys = parameters.keys();
            while (keys.hasMoreElements()) {
                Object key = keys.nextElement();
                String[] value = (String[])parameters.get(key);
                out.print(key + " = " + value[0] + "");
            }
        } else {
            out.print("The cache was empty. You probably haven't filled it yet!");
        }
    }

    private Hashtable getParameters(String id) throws CacheException {
        Hashtable parameters = new Hashtable();
        Set set = cache.getKeys("/" + id);
        if (set != null) {
            Iterator setIterator = set.iterator();
            while (setIterator.hasNext()) {
                String key = (String)setIterator.next();
                parameters.put(key, cache.get("/" + id, key));
            }
        }
        clearCache(id);
        return parameters;
    }

    private void clearCache(String id) throws CacheException {
        cache.remove("/" + id);
    }

}


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877994#3877994

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877994

[Jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Re: JBossIDE Team meeting 05/17

[<max...@jb...>]

Sounds like a good plan

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877989#3877989

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877989

[Jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Re: JBossIDE Team meeting 05/17

[<mcu...@jb...>]

For our release build -- I'm thinking we should follow the WTP model of "candidate builds" and let our components leads each "Ok" the build before it is released upon the world (i.e, run their specific tests etc).

Any thoughts?

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877988#3877988

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877988

[Jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - JBossIDE Team meeting 05/17

[<mcu...@jb...>]

Meeting notes 05/17
----

Things to resolve w/ the IDE build process by the end of the week:
 - Support for update site builds
 - Integrate Koen's jBPM builder into the product build
 - Add inclusion of required plugins into binary distributions

Some features in JBossIDE are currently including external plugins as part of their plugin list to make the PDE build place them inside their binary distribution. The product build now allows for binary requirement downloading (and soon inclusion into the distribution), so any/all features with non-JBossIDE dependant plugins in their feature.xml should remove them and place those dependencies in the "Requirements" section where they belong. (Features that have this: IDE core, EJB3, jBPM..)

Max is working on cleaning things up in Hibernate Tools and will have it ready for release by the end of the week.

We will be using the new build system for this release early next week based on eclipse 3.1M6 and WTP 1.0M4. 

Eclipse 3.1M7 classloading changes are going to affect hibernate, and webtools will need to be updated as well. Our next relase (1.5M3) will focus on the eclipse 3.1M7/ webtools 1.0M5 combo

We want to re-iterate (as much as possible) our need for public APIs to the webtools requirement committee, especially in the area of the SSE.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877987#3877987

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877987

[Jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: org.jboss.ha.framework.server.FarmMemberService behaviou

[garu <nu...@jb...>]

Well, that piece of code contributes to expose a problem that exists during the service startup.

I have been successful in reproducing the following scenario.

1- server starts up and joins the cluster, /farm applications are pulled from remote node.
2- farmDeploy() is called for the applications, remotelyDeployed gets filled with their names
3- scanner thread is started and begins calling deploy() for each application
4- by chance, deploy() executes while service status is still STARTING so it call super.deploy() and applications are deployed but their names are not removed from remotelyDeployed
5- you remove application from /farm and farmUndeploy() is invoked.
6- you put again application in /farm, deploy() is called, super.deploy() is called, BUT remotelyDeployed is still dirty from the preceding deploy so farmDeploy() is not invoked and the application won't get farmed

Then everything cleans up and for subsequent deploy/undeploy works correctly.

Gabriele.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877983#3877983

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877983

[Jboss-dev-forums] [Design of JBossCache] - Re: FileCacheLoader create() Method Implementation

[<be...@jb...>]

Don't you have CVS write access. Go ahead and commit those changes once the FileCacheLoaderTest passes...

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877976#3877976

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877976

[Jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - org.jboss.ha.framework.server.FarmMemberService behaviour

[garu <nu...@jb...>]

I have a question regarding FarmMemberService implementation. (version 4.0.2 final)

During service start, before enabling the scanner thread you call PullNewDeployments(), where you check that remote deployment is newer than local file before pulling it.
The problem is that parentDUMap from which you get the DeployedURL to find local file is only filled by deploy() which was never called yet because the scanner thread is not yet started.
So as far as i understand, on startup parentDUMap is always empty and remote deployments are always pulled despite their date, and even if local files are newer they are overwritten with older remote files before getting any chance to be deployed.
This is indeed the behaviour i see in the test cluster i set up.

My question: is this the intended behaviour and the date check is only a  forgotten piece of code which was not supposed to work or is it a bug and the date check should be corrected?

Thanks, Gabriele.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877952#3877952

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877952

[Jboss-dev-forums] [Design of JBossCache] - Re: FileCacheLoader create() Method Implementation

[jiwils <nu...@jb...>]

"jiwils" wrote : ...I will head down this path and post a feature request with patch to JIRA shortly...
http://jira.jboss.com/jira/browse/JBCACHE-158

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877939#3877939

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877939

[Jboss-dev-forums] [Design of JBossCache] - Re: FileCacheLoader create() Method Implementation

[jiwils <nu...@jb...>]

Based on your response, the removal of the exception throwing behavior is probably the route to take as the addition of a property would not buy us much.  Unless I misread what you wrote (please correct me if so), I will head down this path and post a feature request with patch to JIRA shortly...

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877934#3877934

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877934

[Jboss-dev-forums] [Design of JBossCache] - Re: FileCacheLoader create() Method Implementation

[<be...@jb...>]

"jiwils" wrote : From FileCacheLoader.java:
  | public void create() throws Exception {
  |   |       if(!root.exists())
  |   |          throw new FileNotFoundException(root.toString());
  |   | }
  | Is there a reason that the FileCacheLoader implementation of create throws an exception if the "root" cache loader location is not found rather than just create it?
  | 

No, you can change this

anonymous wrote : 
  | Checking File.canRead() and File.canWrite() might make sense as a sanity check here as well.
  | 

Go ahead

anonymous wrote : 
  | If such a reason exists, would an additional configuration property named createLocation that controlled creation of the "root" cache loader location make sense? .

Okay, under the CacheLoaderConfig attribute would be okay. Go ahead and make those changes, thanks,

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877932#3877932

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877932

[Jboss-dev-forums] [Design of JBossCache] - FileCacheLoader create() Method Implementation

[jiwils <nu...@jb...>]

From FileCacheLoader.java:
public void create() throws Exception {
  |       if(!root.exists())
  |          throw new FileNotFoundException(root.toString());
  | }
Is there a reason that the FileCacheLoader implementation of create throws an exception if the "root" cache loader location is not found rather than just create it?  Checking File.canRead() and File.canWrite() might make sense as a sanity check here as well.

If such a reason exists, would an additional configuration property named createLocation that controlled creation of the "root" cache loader location make sense?  I would be happy to provide a patch via JIRA that provides this behavior.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877931#3877931

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877931

[Jboss-dev-forums] [Design of JBoss Portal] - Re: JBoss Portal runs on AS 4.0.2 final now

[<ju...@jb...>]

actually file are generated but not in the good directory, they are in server output. I take that for a bug of xdoclet. trying to find a solution


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877908#3877908

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877908

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Portlet intercommunication

[dajevtic <nu...@jb...>]

In order to make it work for portlets within seperate webapps, the PortletFormManager.jar should be deployed to the 
"jboss-portal.sar\lib" directory. Then distributed webapp's portlets can use it without any problem.

I have to check the behavior in a distributed environment, but I doubt that it will work, unless I use one of the two possibilities:

1.) Implement persistence for form data
or
2.) Make the PortletFormManager a web service which receives and sends data via http

But I will check so that I can give a 100% educated answer

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877833#3877833

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877833

[Jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - update site version numbering blues

[<max...@jb...>]

Hi guys,

As talked with Marshall I did a small test for how the versioning numbering  affects the update mechanism.

If I make a update site with the following features:

id="nestea.feature" version="1.0.0"
id="nestea.feature" version="1.0.1.N20050516123460"
id="nestea.feature" version="1.0.1.N20060516123460"

Then everything seems to work fine, BUT when I
add 

id="nestea.feature" version="1.0.1

then it is not calculated as the latest version - 
id="nestea.feature" version="1.0.1.N20060516123460" is.

This is not bad if its the first time you install from the site
because you can then choose the proper latest version, but when
you want to update you wont be able to select the versions eclipse 
thinks is "behind" a version.

so if you have 1.0.1.NSOMETHING installed and 1.0.1 is released then you wont be able to install it.

seems like we have to have the nightly builds stay at the last released version number (1.0.0.NXXX) and then only upgrade the actual version 1.0.1 when we want to release)

...any comments/ideas/info on how other plugins does this stuff (besides not providing updatesite for nighlty builds :)

/max


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877803#3877803

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877803

[Jboss-dev-forums] [Design of JBoss Build System] - Re: More on component-info.xml usage

[<rya...@jb...>]

A small problem with this approach is that you will need to uniquely name the thirdparty include id, like this:
      <includes id="thirdparty-naming">
  |          <include component="common"/>
  |          <include component="apache-log4j"/>
  |       </includes>
Anything with an id attribute is a reference.  Since we will be parsing other component-info's, you want the id to be unique so that references are not overriden by other "thirdparty" includes.

Also, there is a small syntax problem in your last code example.  To reference an includes from an include, you use the input attribute:
   <componentdef component="naming" description="JBoss Naming">
  |       <source id="main"
  |               rmic="**/NamingServer.class"
  |       >
  |          <include input="thirdparty"/>
  |          <include component="junit-junit"/>
  |       </source>

Nitpicks aside, I think the design will work.  

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877865#3877865

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877865

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Portlet intercommunication

[<ju...@jb...>]

I would prefer TreeCache (Aop or not), you can look at the code integrating tomcat SessionManager to see how they do it.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877897#3877897

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877897

[Jboss-dev-forums] [Design of JBoss Portal] - Re: JBoss Portal runs on AS 4.0.2 final now

[sgwood <nu...@jb...>]

Ahhh, good. The main build compiles fine now.

The setup module is now broken, as it depends on Hibernate 2.


Sherman

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877904#3877904

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877904