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: rmcdonough <nu...@jb...> - 2005-07-17 14:37:40
|
A couple of questions for you: What version of JBoss AOP are you using? | What JDK version? | How are you invoking your application? Meaning what parameters are you passing to the VM? | | | | Ryan- View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885200#3885200 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885200 |
From: martingi <nu...@jb...> - 2005-07-17 12:10:24
|
"legolas" wrote : Also no localisation is provided, I (ab)used the pages name as key for retrieving the actual localized page name. | I like this approach, because if the page names could be used as a key for retrieval from the page definitions, another benefit would be more simplicity creating links from 'normal' text fragments to already defined pages. At the moment I am creating a new PortletURL for each normal text link to a page, although this is a redundancy since the page is actually already defined. Or maybe I am missing something here? The only way I see at the moment to access the page definitions is getting the iterator of all pages with JBossRenderRequest#getPortalObjects(). Maybe it would be easier to introduce an accessor like getPageByName(pageName) in order include a link to an already defined page. Furthermore an automated link checking (or simple exception throwing) by the portal could be possible with this, if the page should be not defined anymore. "mholzner" wrote : So far I haven't thought about it. What is the use case? Why would you need to do this ? A scenario for per window rendering might be that you have a window rendering the navigation (which you always want to get displayed and where you don't want to have any decorations) and another window with news and window decorations, where you will let it up to the user whether to minimize it or not. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885192#3885192 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885192 |
From: zeroconf <nu...@jb...> - 2005-07-16 21:21:39
|
so - then I just can use the doView() and processAction() method to do some initial stuff with the sessionID? the doView() method get's called first I suppose - so I have to put it in the doView() method when I don't want the user to click any actionURL-link to execute initialization tasks which depend on sessionID?? but this solution seems a bit strange to me in terms of good design - the method is called _view_ which should be (more or less) doing displaying stuff only any suggestions? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885178#3885178 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885178 |
From: <ju...@jb...> - 2005-07-16 20:42:02
|
zeroconf, the init method is not called by a client but is called by the portal when it deploys the portlet. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885177#3885177 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885177 |
From: zeroconf <nu...@jb...> - 2005-07-16 19:54:30
|
Is there any way to access the sessionID within the portlet init()-method. I need this to invoke some classes where the SessionID separates user contexts? thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885172#3885172 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885172 |
From: dblaisdell <nu...@jb...> - 2005-07-16 16:32:59
|
Figured out how to fix this problem. anonymous wrote : | Just change the memory settings for the default JVM that you have | defined in Eclipse. (Meaning, in Preferences under "Installed JREs" | go to the "default VM options" and put some setting like "-Xms192m - | Xmx768m" (minus the quotes). Note of could "ms" is the amount of | memory to assign at startup and "mx" is the maximum that it's allowed | to grow. | | Our system is HUGE and has hundreds of Local and Remote Interfaces, | Message Beans, Value Objects, etc. and generally gets by XDoclet | compiling with 512m. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885163#3885163 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885163 |
From: dblaisdell <nu...@jb...> - 2005-07-16 16:32:08
|
I would like to thank willimur to responding to an e-mail about the ANT_OPTS problem. Here is his solution: anonymous wrote : | Just change the memory settings for the default JVM that you have | defined in Eclipse. (Meaning, in Preferences under "Installed JREs" | go to the "default VM options" and put some setting like "-Xms192m - | Xmx768m" (minus the quotes). Note of could "ms" is the amount of | memory to assign at startup and "mx" is the maximum that it's allowed | to grow. | | Our system is HUGE and has hundreds of Local and Remote Interfaces, | Message Beans, Value Objects, etc. and generally gets by XDoclet | compiling with 512m. | Thank you! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885161#3885161 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885161 |
From: dblaisdell <nu...@jb...> - 2005-07-16 15:17:21
|
I have searched the mailing list and still can't find a solution to this problem. Have either of you figured out how to change the ant memory settings? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885157#3885157 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885157 |
From: <be...@jb...> - 2005-07-16 08:23:22
|
Okay, I modified the document slightly. Search for "BELA" in the text. I'll post the document below (it is also in the CVS, under JBossCache/docs/design). anonymous wrote : | TreeCache Passivation/ Overflow | =============================== | | | | Author: Hany Mesha (hm...@no...) | Revision: $Id: TreeCachePassivation.txt,v 1.3 2005/07/16 08:20:06 bela Exp $: | | JIRA issue: http://jira.jboss.com/jira/browse/JBCACHE-66 | | | Goal: | ----- | | When a cache is full and a new object needs to be loaded into the cache, an | existing object must be removed from the cache to make room for the new object. | However, re-creating and re-loading a large objects in in-memory cache is | expensive. Therefore, Passivation/ Activation is a mechanism to avoid such | performance costly operations. | | When an object is called back by the Eviction Policy Provider in the | TreeCache for eviction, The TreeCache will determine whether to passivate | the object or simply remove it. The decision will be based on the value of | CacheLoaderEnablePassivation flag in the cache loader configuration group | (true/ false) of the cache configuration file. | | Passivation is the process of removing an object from in-memory cache and | persisting it to a secondary data store (i.e. file system, database) on eviction. | | Activation is the process of restoring an object from the data store into the | in-memory cache when it's needed to be used. | | In both cases, the configured CacheLoader will be used to read from the data store | or write to the data store. | | Configuration: | -------------- | - CachePassivation: flag to be set by user to enable/ disable cache passivation | EXAMPLE: | | org.jboss.cache.loader.FileCacheLoader | location=c:\\tmp\\node1 | false | / | false | true | <!-- Cache Passivation for Tree Cache --> | true | | Use Case: | --------- | See Related Issues section at the bottom of this document. | | Design: | ------- | | Passivation | ----------- | 1. implements Interceptor: | -------------------------- | Passivation will be implemented using interceptors; see Refactoring.txt for details on interceptors. | | - TreeCache.createInterceptorChain() will assemble the interceptor stack starting with the passivation | interceptor at the bottom of the stack | | - passivation should be applied for the whole node and its children therefore the passivation interceptor | will only act on node node evict() on the way in. | | | | 2. passivate node on eviction: | ------------------------------ | When the eviction policy in effect calls its evict() (calls TreeCache.evict(fqn) or TreeCacheAop.evict(fqn)) | to evict a node from the underlying cache instance, the passivation interceptor will intercept the call and | store the node and its children in the cache loader store. | | Pseudo code in PassivationInterceptor: | | public Object invoke(MethodCall m) throws Throwable { | Method meth=m.getMethod(); | Object[] args=m.getArgs(); | | if(meth.equals(TreeCache.evictNodeMethodLocal) { | Fqn evictedNode=(Fqn)args[0]; | // the evict() method is called; store the evicted node in the cache loader | loader.store(evictedNode); | } | else { | ... | } | } | | | | Question: | --------- | Should we brute force remove of the node from in-memory cache? | BELA: no, this will be done by the eviction policy. Note that non-leaf nodes | are not removed from memory, but just cleared of their data | | Also, should we make sure that the node is not added to the removal queue otherwise the cache store | interceptor will be triggered to remove it from the cache loader store and will be impossible to activate | the node again? | | Activation: | ----------- | Question | -------- | On incoming get method call, don't do anything and let the call climb up the cache loader interceptor in the | stack or should we handle a get in the cache passivation interceptor to manually get the node from the cache | loader, store it in the in-memory cache, then remove it from the cache loader? If we do so how can we distinguish | between persisted and passivated node? | | BELA: The ActivationInterceptor should *replace* the CacheLoaderInterceptor (similar to the | PassivationInterceptor which replaces the CacheStoreInterceptor). The ActivationInterceptor can simply | extend the CacheLoaderInterceptor and, on GET, call super.GET(), which loades from the store, then remove | the element from the store. Similarly, the PassivationInterceptor could extend CacheStoreInterceptor. | | BELA: passivation and activation *replace* regular cache loading, so we don't need to differentiate | between persisted and passivated objects. You can have either persisted, or passivated, but not both, objects. | | | | 4. Transaction: | --------------- | The cache passivation interceptor will be modeled after the cache store interceptor which is transaction aware. | It will have an inner class SynchronizationHandler which implements transaction synchronization. It will build | transaction modification (EVENT_EVICT) list and pass it to the cache loader on passivation. On activation, it's | a get therefore, there's no transaction process involved. | BELA: maybe we can inherit this from the respective superclasses | | Related Issues: | --------------- | | - JBCLUSTER-15 | Affected packages in cluster: org.jboss.ha.httpsession.server | Currenlty JBoss Clustering HTTP Session replication doesn't support passivation. http session is wraps in an | entity bean to persist the session. ClusteredHTTPSessionService has an inner class, CleanupDaemon, that runs on | a separate thread every 30 seconds to remove the timed out session's EJB object from the entity bean. That | puts the entity bean back in the pool of available instances and the session information not accessiable anymore. | | | To avoid the cost of recreating those EJB objects, ClusteredHTTPSessionService should use JBoss Cache | passivation feature. When the session times out, instead of throwing it away. | | On the other hand, ClusteredHTTPSessionService is a standalone jmx service and doesn't use | org.jboss.ha.framework.server to handle cluster communications. | | There're two ways to handle passivation: | 1. keep the existing jmx service and write custom class that will be modeled after the ejb3 sfsb passivation | 2. Replace the jmx service with HA framework, keep in mind though that passivation will only act on a node and | the HA framework act on a key-value pair, need to be thought through. | | Question: | --------- | Should we use approach 1 or 2? | | - JBCLUSTER-40 | Affected packages in ejb3: org.jboss.ejb3.cache.tree, org.jboss.ejb3.stateful | | Currently ejb3 has its own activation/ passivation mechanism which uses JBoss Cache File cache loader to | passivate and activate sfsb. Once JBoss Cache implements this feature, ejb3 should re-work its passivation | policy to take advantage of the new feature as follow: | 1. Add to org.jboss.cache.TreeCache public EvictionPolicy getEvictionPolicy() and remove org.jboss.ejb3.cache.tree.PassivationTreeCache | 2. Change the implementation in org.jboss.cache.treeCache.StatefulTreeCache. | 3. Add to org.jboss.cache.eviction.BaseEviction public void createRegion(String name, int maxSize, long timeToLive) | and public void removeRegion(String name) to act on the RegionManager. Then, remove org.jboss.ejb3.cache.tree.PassivationEvictionPolicy | 4. Change the implementation in org.jboss.cache.tree.StatefulEvictionPolicy. | 5. Remove org.jboss.ejb3.cache.tree.PassivationCacheLoader, | 6. Change the implementation in org.jboss.ejb3.cache.tree.StatefulCacheLoader | 7. Refactor the changes in org.jboss.ejb3.stateful where necessary | 8. turn the passivation flag to true in the cache service on the sfsb container startup??? | | - JBCACHE-159 | NOT YET FINISHED. | | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885128#3885128 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885128 |
From: oberon777 <nu...@jb...> - 2005-07-16 06:19:26
|
The trouble stems from using expanded war archives, actually. But thanks for the pointer. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885120#3885120 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885120 |
From: nthx <nu...@jb...> - 2005-07-16 00:35:54
|
Hi there! http://www.ii.uni.wroc.pl/~nthx/blog/blog_19012005.html might help a little bit. Take care - Tomasz Nazar PS. It may be little out dated. If so, notify me please.. PS2. There is of course entry in official JBAOP docs about your problem: "packaging aspects" or sth similar.. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885111#3885111 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885111 |
From: oberon777 <nu...@jb...> - 2005-07-15 22:27:17
|
I am having trouble deploying aspects withing JBoss AS. The issue is that I have the application which runs fine, but no aspects are applied. I am trying to use a combination of "org.jboss.aop.deployment.AspectManagerService" without pluggable-instrumentor. The application is snipsnap and it's located under $JBOSS_HOME/server/default/deploy/jboss-aop-jdk50.deployer/snipsnap.war, which is an expanded directory. The reason I expanded the directory is because the application needs to store its setting, which would get wiped out if a war file is expanded each time. The application runs just fine. However, I don't know how to package the aspects. I tried pretty much all combinations of locations without any success. I have a jboss-aop.xml file that looks like this | 1 <?xml version="1.0" encoding="UTF-8"?> | 2 <aop> | 3 <bind pointcut="call(* org.snipsnap.*->*(..))"> | 4 <interceptor class="CallerInterceptor"/> | 5 </bind> | 6 </aop> | which is located under snipsnap.war/META-INF/. Class file CallerInterceptor is located under the snipsnap.war/ directory. However, the aspect is just not being picked up. Please help. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885107#3885107 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885107 |
From: <rl...@jb...> - 2005-07-15 21:18:26
|
As suggested, I was able to move the installation targets from the main build.xml file and into a build-distr.xml file (work done locally). At this point I am ready to commit and perform integration testing on the thirdparty build system. In order to not disturb development during this period we will create a branch to do this. Ruel Loehr JBoss QA View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885102#3885102 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885102 |
From: dblaisdell <nu...@jb...> - 2005-07-15 20:31:11
|
i'm getting a very similar error | N10004: | [ejbdoclet] null | [ejbdoclet] ParameterImpl instances: 20 | [ejbdoclet] MethodImpl instances: 6605 | [ejbdoclet] ConstructorImpl instances: 272 | [ejbdoclet] SimpleNode instances: 0 | [ejbdoclet] SourceClass instances: 449 | [ejbdoclet] XDoc instances: 44 | [ejbdoclet] DefaultXTag instances: 139 | [ejbdoclet] BinaryClass instances: 49 | [ejbdoclet] UnknownClass instances: 0 | [ejbdoclet] Total memory: 63 | [ejbdoclet] Free memory: 0 | [ejbdoclet] Try to increase heap size. Can be done by defining ANT_OPTS=-Xmx640m | [ejbdoclet] See the JDK tooldocs. | How can I fix this? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885099#3885099 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885099 |
From: dblaisdell <nu...@jb...> - 2005-07-15 19:44:34
|
Anyone found a solution to this error yet? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885092#3885092 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885092 |
From: <ad...@jb...> - 2005-07-15 18:31:03
|
This forum is for discussions around the implementation of JBoss's webserver integration. If you want to discuss Tomcat issues go here: http://www.jboss.org/index.html?module=bb&op=viewforum&f=172 If you are asking for help, use the user forums http://www.jboss.org/index.html?module=bb&op=viewforum&f=50 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885083#3885083 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885083 |
From: <ad...@jb...> - 2005-07-15 18:29:49
|
This forum is for discussions around the implementation of JBoss's Tomcat integration. If you want to discuss the implementation of general webserver integration go here: http://www.jboss.org/index.html?module=bb&op=viewforum&f=167 If you are asking for help, use the user forums http://www.jboss.org/index.html?module=bb&op=viewforum&f=50 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885082#3885082 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885082 |
From: <ad...@jb...> - 2005-07-15 18:08:25
|
We might be able to do something with the extension points http://java.sun.com/j2se/1.5.0/docs/api/javax/management/remote/JMXConnectorServer.html#setMBeanServerForwarder(javax.management.remote.MBeanServerForwarder) or jmx.remote.protocol.provider.class.loader http://java.sun.com/j2se/1.5.0/docs/api/javax/management/remote/JMXConnectorServerFactory.html I'm not that familiar with JSR160 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885079#3885079 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885079 |
From: <sco...@jb...> - 2005-07-15 17:41:16
|
I think a new jmx remote connector is what we really need, because even with the current workaround, there are still the problems of accessing objects that are not really designed for remote access. We need a flexible connector that can be configured for remote class loading and even custom serialization/object replacement of non-remotable objects. I would have looked at this first but I was not sure how far Tom has gotten with the current implementation. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885074#3885074 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885074 |
From: lbecarelli <nu...@jb...> - 2005-07-15 17:34:30
|
Hello, i had same classes in /share/classes for tomcat 5.5.7 folder that are for all web application. Can i reload new classes whitout restart tomcat ??? If i use JBoss can i resolve this problem ??? Tks for all. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885073#3885073 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885073 |
From: <ad...@jb...> - 2005-07-15 17:19:01
|
Or Scott's alternative LazyMBeanServer. http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMBeansInJConsole that delegates to JBoss's MBeanServer (when it is available) for non platform XMBeans. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885072#3885072 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885072 |
From: <ad...@jb...> - 2005-07-15 17:11:22
|
Following up on http://jira.jboss.com/jira/browse/JBAS-1610 The issue is that to start the agent for jconsole "-Dcom.sun.management.jmxremote" we must have JBossJMX in the CLASSPATH rather than having ServerImpl setup the system properties and classloader. We cannot use Sun's MBeanServer because 1) We cannot plugin our UnifiedLoaderRepository 2) It does not do MBean context classloading 3) It is slow for Standard/ModelMBean (see the performance tests in the jmx module) In fact when we did use Sun's MBeanServer in 2.4.x we had to implement performance critical mbeans like the EJBContainer using DynamicMBeans. Other alternatives: 1) Write a listener for MBeanRegistration events that creates proxies from the platform mbean server to the JBoss MBeanServer (a poor man's cascading MBeanServer) 2) Deploy a jmx remote connector in JBoss's MBeanServer and use the remote tab to connect to it from jconsole (including adding the platform XMBeans to JBoss's MBeanServer). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885071#3885071 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885071 |
From: wittnebel <nu...@jb...> - 2005-07-15 17:05:21
|
Ich soll eine J2EE Applikation schreiben, die EJBs als Middleware benutzt. Auf die Middleware soll mit Hilfe eines Swing Clients zugegriffen werden. Als Voruebung habe ich einen TestClient entwickelt (siehe Anlage), der den Namen der EJB mittels JNDI im Initialcontext nachgucken soll. Aber es geht schon bei der Instanziierung des Initialkontexts schief, die Anmeldekonfiguration kann nicht gefunden werden. Dabei habe ich in den Properties fuer den Initialkontext auch den Ort der auth.conf angegeben. Kann mir jemand bitte einen Tip geben? Anna //15.Juli 2005 package de.mpg.mpimbonn.transaction; import javax.naming.Context; import javax.naming.InitialContext; import javax.rmi.PortableRemoteObject; import de.mpg.mpimbonn.ejb.Example; import de.mpg.mpimbonn.ejb.ExampleHome; import java.util.Properties; public class TestClient { public Context login(String user, String password) { Context ctx = null; Properties p = new Properties(); p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.LoginInitialContextFactory"); p.put(Context.PROVIDER_URL, "jnp://localhost:1099"); p.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces"); p.put(Context.SECURITY_AUTHENTICATION, "file:///C:/j2ee/jboss-4.0.2/client/auth.conf"); p.put(Context.SECURITY_PROTOCOL, "login"); p.put(Context.SECURITY_PRINCIPAL, user); p.put(Context.SECURITY_CREDENTIALS, password); try{ ctx = new InitialContext(p); }catch(Exception e){ System.out.println("Schon bei der Instanziierung des "); System.out.println("Initialkontextes geht was schief! "); System.out.println("Grund "+e.getCause()); e.getMessage(); e.printStackTrace(); } return ctx; } public static void main(String[] args) { TestClient test = new TestClient(); Context initial = test.login("200","j2ee"); try{ Object ref = null; if(initial!=null){ ref = initial.lookup("java:comp/env/ejb/Example"); }else{ System.out.println("InitialContext ist null!"); } ExampleHome home = (ExampleHome) PortableRemoteObject.narrow (ref, ExampleHome.class); Example example = home.create(); }catch(Exception e){ e.getMessage(); e.printStackTrace(); } }//end main() }//end class TestClient View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885069#3885069 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885069 |
From: <tho...@jb...> - 2005-07-14 19:56:55
|
Please goto the user forum, this post will be removed View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884911#3884911 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884911 |
From: hmesha <nu...@jb...> - 2005-07-14 18:34:33
|
Hello all, Let me first introduce myself, My name is Hany Morris Mesha. I work for Novell web applications R&D. I've recently joined the effort on JBoss Cache development. I started the design for JBCACHE-66 and had discussions with Bela and Ben about the approach to be take in the design. Based on those discussions I have created a design document and checked it in under JBossCache/docs/design/TeeCachePassivation.txt. I have 3 questions listed in the document that I'd appreciate your input on as well as anything else you might see in there. Please review the design and let me know your opinion. Thanks, - Hany View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884892#3884892 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884892 |