[Beginner's Corner] New message: "Re: Configure webapp to accept requests only from a specific port"
by y lp
User development,
A new message was posted in the thread "Configure webapp to accept requests only from a specific port":
http://community.jboss.org/message/530666#530666
Author : y lp
Profile : http://community.jboss.org/people/ylp_1
Message:
--------------------------------------------------------------
some about Remote Address valve .
maybe you can use java regex to filter differert ports
| |
| > | |
> | > The *Remote Address Filter* allows you to compare the IP address of the client that submitted this request against one or more +regular expressions+, and either allow the request to continue or refuse to process the request from this client. A Remote Address Filter can be associated with any Catalina container (/engine.html, /host.html, or /context.html), and must accept any request presented to this container for processing before it will be passed on.
> > The syntax for +regular expressions+ is different than that for 'standard' wildcard matching. Tomcat uses the java.util.regex package. Please consult the Java documentation for details of the expressions supported. |
> | |
> | > The *Remote Address Filter* supports the following configuration attributes:
> > || Attribute || Description ||
> > | *className* | Java class name of the implementation to use. This MUST be set to *org.apache.catalina.valves.RemoteAddrValve*. |
> > | allow | A comma-separated list of +regular expression+ patterns that the remote client's IP address is compared to. If this attribute is specified, the remote address MUST match for this request to be accepted. If this attribute is not specified, all requests will be accepted UNLESS the remote address matches a deny pattern. |
> > | deny | A comma-separated list of +regular expression+ patterns that the remote client's IP address is compared to. If this attribute is specified, the remote address MUST NOT match for this request to be accepted. If this attribute is not specified, request acceptance is governed solely by the accept attribute. |
> > |
> |
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530666#530666
16 years, 1 month
[jBPM] New message: "Data deleted from History tables in the database (4.3)"
by Ryan Bartlett
User development,
A new message was posted in the thread "Data deleted from History tables in the database (4.3)":
http://community.jboss.org/message/530663#530663
Author : Ryan Bartlett
Profile : http://community.jboss.org/people/RyanLBart
Message:
--------------------------------------------------------------
Is there anything that would trigger the deletion of all of the rows in the JBPM4_HIST_* tables? Would deploying the same process definition (name, key, id) multiple times to the same repository service delete the history rows? I have not defined a transaction manager (I am using the all of the default configuration files); therefore, I am assuming it isn't a matter of the data not being commited which I assumed was done when I call...
executionService.endProcessInstance(processInstanceId, "end");
where 'end' is defined as...
<end name='end'></end>
Thanks in advance!
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530663#530663
16 years, 1 month
[Beginner's Corner] New message: "Re: Configure webapp to accept requests only from a specific port"
by y lp
User development,
A new message was posted in the thread "Configure webapp to accept requests only from a specific port":
http://community.jboss.org/message/530662#530662
Author : y lp
Profile : http://community.jboss.org/people/ylp_1
Message:
--------------------------------------------------------------
This is tomcat 6 server.xml, i tested it works fine，but i had't teste it in jboss. i will have a try about using valve.
<!-- Note: A "Server" is not itself a "Container", so you may not
define subcomponents such as "Valves" at this level.
Documentation at /docs/config/server.html
-->
<Server port="8005" shutdown="SHUTDOWN">
<!--APR library loader. Documentation at /docs/apr.html -->
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
<Listener className="org.apache.catalina.core.JasperListener" />
<!-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html -->
<Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<!-- Global JNDI resources
Documentation at /docs/jndi-resources-howto.html
-->
<GlobalNamingResources>
<!-- Editable user database that can also be used by
UserDatabaseRealm to authenticate users
-->
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<!-- A "Service" is a collection of one or more "Connectors" that share
a single "Container" Note: A "Service" is not itself a "Container",
so you may not define subcomponents such as "Valves" at this level.
Documentation at /docs/config/service.html
-->
<Service name="Catalina">
<!--The connectors can use a shared executor, you can define one or more named thread pools-->
<!--
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="150" minSpareThreads="4"/>
-->
<!-- A "Connector" represents an endpoint by which requests are received
and responses are returned. Documentation at :
Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
Java AJP Connector: /docs/config/ajp.html
APR (HTTP/AJP) Connector: /docs/apr.html
Define a non-SSL HTTP/1.1 Connector on port 8080
-->
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
compressionLevel="1000"
/>
<!-- A "Connector" using the shared thread pool-->
<!--
<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
<!-- Define a SSL HTTP/1.1 Connector on port 8443
This connector uses the JSSE configuration, when using APR, the
connector should be using the OpenSSL style configuration
described in the APR documentation -->
<!--
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
-->
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<!-- An Engine represents the entry point (within Catalina) that processes
every request. The Engine implementation for Tomcat stand alone
analyzes the HTTP headers included with the request, and passes them
on to the appropriate Host (virtual host).
Documentation at /docs/config/engine.html -->
<!-- You should set jvmRoute to support load-balancing via AJP ie :
<Engine name="Standalone" defaultHost="localhost" jvmRoute="jvm1">
-->
<Engine name="Catalina" defaultHost="localhost">
<!--For clustering, please take a look at documentation at:
/docs/cluster-howto.html (simple how to)
/docs/config/cluster.html (reference documentation) -->
<!--
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
-->
<!-- The request dumper valve dumps useful debugging information about
the request and response data received and sent by Tomcat.
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.valves.RequestDumperValve"/>
-->
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
<!-- Define the default virtual host
Note: XML Schema validation will not work with Xerces 2.2.
-->
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>
-->
</Host>
</Engine>
</Service>
<Service name="Catalina1">
<!--The connectors can use a shared executor, you can define one or more named thread pools-->
<!--
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="150" minSpareThreads="4"/>
-->
<!-- A "Connector" represents an endpoint by which requests are received
and responses are returned. Documentation at :
Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
Java AJP Connector: /docs/config/ajp.html
APR (HTTP/AJP) Connector: /docs/apr.html
Define a non-SSL HTTP/1.1 Connector on port 8080
-->
<Connector port="8081" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
compressionLevel="1000"
/>
<!-- A "Connector" using the shared thread pool-->
<!--
<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
<!-- Define a SSL HTTP/1.1 Connector on port 8443
This connector uses the JSSE configuration, when using APR, the
connector should be using the OpenSSL style configuration
described in the APR documentation -->
<!--
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
-->
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<!-- An Engine represents the entry point (within Catalina) that processes
every request. The Engine implementation for Tomcat stand alone
analyzes the HTTP headers included with the request, and passes them
on to the appropriate Host (virtual host).
Documentation at /docs/config/engine.html -->
<!-- You should set jvmRoute to support load-balancing via AJP ie :
<Engine name="Standalone" defaultHost="localhost" jvmRoute="jvm1">
-->
<Engine name="Catalina" defaultHost="localhost">
<!--For clustering, please take a look at documentation at:
/docs/cluster-howto.html (simple how to)
/docs/config/cluster.html (reference documentation) -->
<!--
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
-->
<!-- The request dumper valve dumps useful debugging information about
the request and response data received and sent by Tomcat.
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.valves.RequestDumperValve"/>
-->
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
<!-- Define the default virtual host
Note: XML Schema validation will not work with Xerces 2.2.
-->
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>
-->
</Host>
</Engine>
</Service>
</Server>
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530662#530662
16 years, 1 month
[JBoss Microcontainer] New message: "Re: Sub deployer not kicking in on CreateDestinationDeployer"
by Clebert Suconic
User development,
A new message was posted in the thread "Sub deployer not kicking in on CreateDestinationDeployer":
http://community.jboss.org/message/530650#530650
Author : Clebert Suconic
Email : clebert.suconic(a)jboss.com
Profile : http://community.jboss.org/people/clebert.suconic@jboss.com
Message:
--------------------------------------------------------------
I have tried adding a dependency on HornetQJMSRealDeployer to the HornetQDestinationCreator and it still didn't work.
<!-- Destination creator for HornetQ
This gets "automagically" injected into CreateDestinationDeployer Bean at ejb-deployer-jboss.xml through incallback and uncallback
-->
<bean name="HornetQDestinationCreator" class="org.jboss.ejb.deployers.CreateDestination">
<!-- We match any jms mdb that is going to be deployed using our rar -->
<property name="matcher">
<bean class="org.jboss.ejb.deployers.SimpleCreateDestinationMatcher">
<property name="default">true</property>
<property name="messageListener">javax.jms.MessageListener</property>
<property name="rarName">hornetq-ra.rar</property>
</bean>
</property>
<!-- Create a destination with HornetQ -->
<property name="factory">
<bean class="org.jboss.as.integration.hornetq.deployers.DestinationFactoryDeployerPlugin"/>
</property>
</bean>
<bean name="HornetQJMSRealDeployer" class="org.jboss.as.integration.hornetq.deployers.HornetQJMSRealDeployer">
<depends>HornetQDestinationCreator</depends>
</bean>
I have also tried the opposite. having the DestinationCreator depending on the JMSRealDeployer, and still no luck.
I'm basically adding the output class by using this method:
unit.getTransientManagedObjects().addAttachment(JMSConfiguration.class.getName(), config, JMSConfiguration.class);
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530650#530650
16 years, 1 month
[JBoss Tools] New message: "Re: JBoss AS WTP server adapter removes deployment module"
by henk de boer
User development,
A new message was posted in the thread "JBoss AS WTP server adapter removes deployment module":
http://community.jboss.org/message/530649#530649
Author : henk de boer
Profile : http://community.jboss.org/people/henk53
Message:
--------------------------------------------------------------
> dgolovin wrote:
>
> As said above you have EAR, EJB and WAR projects. Are they just regular WTP projects? Do you have any additional features enabled for those projects?
It mainly concerns an EAR project, which consists of one EJB module and one WAR module. It is absolutely a regular WTP project, although one with a history that goes way back. Originally it was only a MyEclipse web project in 2003, which got upgraded to newer versions of Java, newer versions of MyEclipse, etc. Then at some time it was converted to a MyEclipse EAR project, then converted to a WTP project and then recently the WAR module was renamed.
I think we've been careful to remove all old cruft, basically by creating new projects and copying the resources over, but it's not unthinkable of course that some old stuff lingers behind. I did a check with a newly generated project again to compare configuration files and I couldn't really find anything obvious. If there's any possible suspected config file for which I need to post its content, please let me know.
I don't really have a lot of additional features enabled, just the standard JSF facet. I also don't have a lot of plug-ins installed. My installation consists of Eclipse Java EE edition, JBoss AS Tools (just the server adapter) and the Subversive SVN plug-in (latest, instead of the 3.5 semi-bundled one). One thing that is ruled out is my computer, OS or Eclipse installation, since I encounter the problem at two totally different workstations (one OS X based, one Ubuntu based).
The thing with creating the JIRA issue is that it's fairly hard to reproduce, although it seems to happen most often if I initially changed some files while the server was running, then stop the server, change some more files and then start it again. If it's allowed to create such 'vague' issues, with difficult to reproduce problems, I'll put that in the issue.
Since we actually have two different issues here and Jan seems to have more details about the issue where a recently saved file actually appears as-if it had been made a deployable artifact, I think it's better that he creates an issue for that. I'll create another issue then about the case where the deployment still looks all right and where a simple clean fixes matters again.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530649#530649
16 years, 1 month
[JBoss Cache] New message: "Clustered invalidation with cacheloader broken removeNode for non-leaf nodes."
by Jacob Barrett
User development,
A new message was posted in the thread "Clustered invalidation with cacheloader broken removeNode for non-leaf nodes.":
http://community.jboss.org/message/530646#530646
Author : Jacob Barrett
Profile : http://community.jboss.org/people/jbarrett
Message:
--------------------------------------------------------------
In JBossCache 3.2.1 I have a clustered cache configuration based on mvcc-entity but I added a cache loader. I am trying to use this to replace an old page content cache system. As a web page's content is collected the results are cached. The next visit will load the content from page and render the page. Pretty straight forward so far. The cache is arranged in a hierarchy, for this example lets say /SITE/AREA/ID. All content is cached at leaf node in the cache under the ID. If someone updates some content on the site we are calling removeNode("/SITE"). This replicates and invalidate node command to the other nodes in the cluster. Without a cache loader this all works great. The other clusters invalidate the node and all its children. The problem comes up when in introduce a cache loader. We want the cache loader because the cached content can be multiple GBs in a very short period of time. We want only the active stuff in the memory cache and the less active stuff evicted to the store. This all behaves fine until we delete the /SITE node.
When the /SITE node is deleted on host A it wipes it from memory and from the loader. It then send the invalidate to host B. Host B marks the node and its children as invalid in memory but does nothing with the cache loader and the content remains in the loader. If host B is requested for content under /SITE it sees that the in memory /SITE is invalid and loads it from the cache loader. At this point it loads the old stale data out of the loader since it never gets wiped.
To make matters worse it appears that the in memory cache of /SITE on B is fubared in that it will never invalidate locally after this point. If the removeNode is called on host B it fails silently leaving the content cached in /SITE.
I have tried both shared and non-shared cacheloaders with the same result. Removing the cacheloaders works but is not a complete solution for our needs.
If I make every node a leaf node it works fine, but then we can't just whack all cache for /SITE and its children which makes cache invalidation impossible given the already sketchy nature of the cache I am replacing.
Has anyone successfully use invalidation with a cacheloader? It seems like an obvious combination especially when the cacheloader is shared.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530646#530646
16 years, 1 month