11:22 p.m.
One of the changes in JBoss AS 5 that comes as a surprise for many
Seam developers/users familiar with the behavior of JBoss AS 4 is the
automatic loading of persistence units from /META-INF/persistence.xml.
(As expected, we had to change several of the Seam examples to
accommodate this change). This is one of those configuration by
exception features in Java EE 5, with one significant exception. While
the container will locate the /META-INF/persistence.xml file on its
own, a container that goes by the book will only deploy the
persistence unit if a resource reference is declared in the descriptor
file (web.xml or ejb-jar.xml). JBoss AS does not wait for this signal.
In my opinion, there is a problem with the JBoss AS approach. What if
you have persistence units that you don't want to deploy? One use case
is that you have persistence units for different environments and a
configuration file can toggle between them. Another use case is that
you have another library, such as Spring or Seam, which bootstraps the
persistence unit instead. Sure, you could rename the file, but then
you break all the IDE behavior that expects the file to be named
persistence.xml. Personally, I think there should be some way to
disable the behavior in JBoss AS and make it look for the persistence
unit references. I agree to keep the automatic loading as the default,
but it is pretty inconvenient not to be able to disable it.
Anyone else agree? Disagree? Why?
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
2:22 a.m.
If you dont want a PC in that deployment, dont put the persistence.XML
file in the ear. I dont get the problem.
Sent from my iPhone
On Dec 1, 2008, at 4:22 PM, "Dan Allen" <dan.j.allen(a)gmail.com> wrote:
One of the changes in JBoss AS 5 that comes as a surprise for many
Seam developers/users familiar with the behavior of JBoss AS 4 is the
automatic loading of persistence units from /META-INF/persistence.xml.
(As expected, we had to change several of the Seam examples to
accommodate this change). This is one of those configuration by
exception features in Java EE 5, with one significant exception. While
the container will locate the /META-INF/persistence.xml file on its
own, a container that goes by the book will only deploy the
persistence unit if a resource reference is declared in the descriptor
file (web.xml or ejb-jar.xml). JBoss AS does not wait for this signal.
In my opinion, there is a problem with the JBoss AS approach. What if
you have persistence units that you don't want to deploy? One use case
is that you have persistence units for different environments and a
configuration file can toggle between them. Another use case is that
you have another library, such as Spring or Seam, which bootstraps the
persistence unit instead. Sure, you could rename the file, but then
you break all the IDE behavior that expects the file to be named
persistence.xml. Personally, I think there should be some way to
disable the behavior in JBoss AS and make it look for the persistence
unit references. I agree to keep the automatic loading as the default,
but it is pretty inconvenient not to be able to disable it.
Anyone else agree? Disagree? Why?
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than
a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a
message if
you feel that it did not reach my attention.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
5:18 a.m.
There is merit to both sides of this argument, but I believe there are
cases when it's not just as easy as just taking the persistence unit
out of the persistence.xml file. For instance, if you want Seam or
Spring to bootstrap the persistence unit instead of the Java EE
container, you are in a bit of a fix, especially if you plan to use
the Java SE standard way of loading the persistence unit (you can
obviously go around it like Spring does and load a file with a
different name). Also, what you gain by convention (loading all
persistence units in persistence.xml) you lose in build complexity.
For instance, Hibernate Tools allows you to have multiple persistence
units defined in persistence.xml which you can use for testing
queries, but then you have to extract those in your build logic before
deploying. Definitely worth doing for a production build, but not
something to worry about early on in development.
All I'm saying is that I can anticipate plenty of scenarios where I
will need to disable this automatic loading of persistence units (or
selective loading) and right now, I don't see a way to do it in JBoss
AS 5. I'm willing to say that the default behavior is what we want,
but I strongly believe that there has to be some control over this
mechanism.
-Dan
On Mon, Dec 1, 2008 at 8:22 PM, Gavin King <gavin.king(a)gmail.com> wrote:
If you dont want a PC in that deployment, dont put the
persistence.XML file
in the ear. I dont get the problem.
Sent from my iPhone
On Dec 1, 2008, at 4:22 PM, "Dan Allen" <dan.j.allen(a)gmail.com> wrote:
> One of the changes in JBoss AS 5 that comes as a surprise for many
> Seam developers/users familiar with the behavior of JBoss AS 4 is the
> automatic loading of persistence units from /META-INF/persistence.xml.
> (As expected, we had to change several of the Seam examples to
> accommodate this change). This is one of those configuration by
> exception features in Java EE 5, with one significant exception. While
> the container will locate the /META-INF/persistence.xml file on its
> own, a container that goes by the book will only deploy the
> persistence unit if a resource reference is declared in the descriptor
> file (web.xml or ejb-jar.xml). JBoss AS does not wait for this signal.
>
> In my opinion, there is a problem with the JBoss AS approach. What if
> you have persistence units that you don't want to deploy? One use case
> is that you have persistence units for different environments and a
> configuration file can toggle between them. Another use case is that
> you have another library, such as Spring or Seam, which bootstraps the
> persistence unit instead. Sure, you could rename the file, but then
> you break all the IDE behavior that expects the file to be named
> persistence.xml. Personally, I think there should be some way to
> disable the behavior in JBoss AS and make it look for the persistence
> unit references. I agree to keep the automatic loading as the default,
> but it is pretty inconvenient not to be able to disable it.
>
> Anyone else agree? Disagree? Why?
>
> -Dan
>
> --
> Dan Allen
> Software consultant | Author of Seam in Action
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
> NOTE: While I make a strong effort to keep up with my email on a daily
> basis, personal or other work matters can sometimes keep me away
> from my email. If you contact me, but don't hear back for more than a
> week,
> it is very likely that I am excessively backlogged or the message was
> caught in the spam filters. Please don't hesitate to resend a message if
> you feel that it did not reach my attention.
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
11:34 a.m.
but I strongly believe that there has to be some control over this
mechanism.
There is plenty of control, if you know how to enable it. ;-)
By order of severity:
1) remove or replace deployer that adds this behavior
- writing new MC deployers is trivial
2) add new deployer that alters this behavior
- MC deployers are metadata driven chain
3) add new structure deployer
- e.g. custom Seam structure
4) limit where persistence.xml is valid (see jboss-structure.xml)
- https://www.jboss.org/community/docs/DOC-13178
5) rename files: persistence.xml --> persistence-xyz.xml
If this kicks in via @PersistenceContext:
1) limit scanning (as I already posted in JIRA):
- https://www.jboss.org/community/docs/DOC-13178 (see jboss-scanning.xml)
If you need any help with writing this,
either post on MC or JBoss5 user forum.
2:32 p.m.
If you dont want a PC in that deployment, dont put the
persistence.XML
file in the ear. I dont get the problem.
As Dan notice, IDE's (especially Eclipse JPA support) uses the standard
deploy structure to figure out the defaults automatically.
Eclipse JPA sucks because it can't support a persistence.xml in another
location;
Hibernate tools (actually hibernate core) also sucks because of this.
JBoss AS also sucks here if it forces a scan without the option to control
it.
Spring is actually good here since it allows you to use the default
structure or
simply specify your own location.
We should fix AS 5 to have something that can allow it to be disabled
(preferably
without having to change AS 5 structure deployers as Ales suggest)
Hibernate Tools will be adjusted (when I can) to do similar as Spring and
manually
build a persistence unit based on an alternative location.
Eclipse JPA will be harder because they only release once a year so even
if we
could fix it for them we can't see that fix before next summer.
btw. this is not a specific issues for persistence.xml; similar problems
exists
for any configuration file in JEE or any other framework where a specific
location
in the classpath is hardcoded (in either the framework or the tooling)
/max
Sent from my iPhone
On Dec 1, 2008, at 4:22 PM, "Dan Allen" <dan.j.allen(a)gmail.com> wrote:
> One of the changes in JBoss AS 5 that comes as a surprise for many
> Seam developers/users familiar with the behavior of JBoss AS 4 is the
> automatic loading of persistence units from /META-INF/persistence.xml.
> (As expected, we had to change several of the Seam examples to
> accommodate this change). This is one of those configuration by
> exception features in Java EE 5, with one significant exception. While
> the container will locate the /META-INF/persistence.xml file on its
> own, a container that goes by the book will only deploy the
> persistence unit if a resource reference is declared in the descriptor
> file (web.xml or ejb-jar.xml). JBoss AS does not wait for this signal.
>
> In my opinion, there is a problem with the JBoss AS approach. What if
> you have persistence units that you don't want to deploy? One use case
> is that you have persistence units for different environments and a
> configuration file can toggle between them. Another use case is that
> you have another library, such as Spring or Seam, which bootstraps the
> persistence unit instead. Sure, you could rename the file, but then
> you break all the IDE behavior that expects the file to be named
> persistence.xml. Personally, I think there should be some way to
> disable the behavior in JBoss AS and make it look for the persistence
> unit references. I agree to keep the automatic loading as the default,
> but it is pretty inconvenient not to be able to disable it.
>
> Anyone else agree? Disagree? Why?
>
> -Dan
>
> --Dan Allen
> Software consultant | Author of Seam in Action
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
> NOTE: While I make a strong effort to keep up with my email on a daily
> basis, personal or other work matters can sometimes keep me away
> from my email. If you contact me, but don't hear back for more than a
> week,
> it is very likely that I am excessively backlogged or the message was
> caught in the spam filters. Please don't hesitate to resend a message
> if
> you feel that it did not reach my attention.
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
/max
2:45 p.m.
We should fix AS 5 to have something that can allow it to be disabled
(preferably
without having to change AS 5 structure deployers as Ales suggest)
See my #4 --> jboss-structure.xml.
Changing structure deployers was more severe option. ;-)
jboss-structure.xml is non invasive,
it will work on JBossAS, but won't interfere with other environments.
Or what more do you want? :-)
2:50 p.m.
Could you give me an example on how to use jboss-structure.xml to have it
not pick-up META-INF/persistence.xml even if it is there
(i.e. to allow a thirdparty library pick it up) ?
/max
> We should fix AS 5 to have something that can allow it to be
disabled
> (preferably
> without having to change AS 5 structure deployers as Ales suggest)
See my #4 --> jboss-structure.xml.
Changing structure deployers was more severe option. ;-)
jboss-structure.xml is non invasive,
it will work on JBossAS, but won't interfere with other environments.
Or what more do you want? :-)
--
/max
3:07 p.m.
It depends if you need any other metadata file from that META-INF directory.
If no, then simply exclude that META-INF as metadata path.
If yes, I currently cannot see how we can handle that,
unless you remove certain deployer.
How do others handle this?
As this is contradiction, since you expect for all other things to work
out-of-the-box,
but not this one + you're not willing to change core configuration.
Beats me. :-)
Max Rydahl Andersen wrote:
Could you give me an example on how to use jboss-structure.xml to
have
it not pick-up META-INF/persistence.xml even if it is there
(i.e. to allow a thirdparty library pick it up) ?
/max
>> We should fix AS 5 to have something that can allow it to be disabled
>> (preferably
>> without having to change AS 5 structure deployers as Ales suggest)
>
> See my #4 --> jboss-structure.xml.
> Changing structure deployers was more severe option. ;-)
>
> jboss-structure.xml is non invasive,
> it will work on JBossAS, but won't interfere with other environments.
>
> Or what more do you want? :-)
3:19 p.m.
On Tue, 02 Dec 2008 15:07:31 +0100, Ales Justin <ales.justin(a)gmail.com>
wrote:
It depends if you need any other metadata file from that META-INF
directory.
If no, then simply exclude that META-INF as metadata path.
If yes, I currently cannot see how we can handle that,
unless you remove certain deployer.
How do others handle this?
As this is contradiction, since you expect for all other things to work
out-of-the-box,
but not this one + you're not willing to change core configuration.
Beats me. :-)
AS 4.x did not do this, so it was never an issue before - hence looking
for ways
to have those apps still be able to deploy without a lot of changes.
We are not saying the default is bad, just that we would like to control
it for
issues listed.
/max
Max Rydahl Andersen wrote:
> Could you give me an example on how to use jboss-structure.xml to have
> it not pick-up META-INF/persistence.xml even if it is there
> (i.e. to allow a thirdparty library pick it up) ?
> /max
>
>>> We should fix AS 5 to have something that can allow it to be disabled
>>> (preferably
>>> without having to change AS 5 structure deployers as Ales suggest)
>>
>> See my #4 --> jboss-structure.xml.
>> Changing structure deployers was more severe option. ;-)
>>
>> jboss-structure.xml is non invasive,
>> it will work on JBossAS, but won't interfere with other environments.
>>
>> Or what more do you want? :-)
>
--
/max
3:33 p.m.
AS 4.x did not do this, so it was never an issue before - hence
looking
for ways
to have those apps still be able to deploy without a lot of changes.
AS 4.x did not have a lot of things. ;-)
We are not saying the default is bad, just that we would like to
control
it for issues listed.
That's how the default work.
Argue with the spec, not me.
We cannot do anything w/o any user explicit info.
The stuff I listed in my 1st email is what we can do.
And I think it's fairly useful list / features.
3:57 p.m.
There is plenty of control, if you know how to enable it. ;-)
And that is the key. Thanks for providing the "how".
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
4:01 p.m.
AS 4.x did not have a lot of things. ;-)
Yep, and I am very glad to see them in JBoss AS 5.
> We are not saying the default is bad, just that we would like to
control
> it for issues listed.
That's how the default work.
Argue with the spec, not me.
As far as I know, though I'm open to be proved wrong, according to the
spec the persistence units are only loaded when a reference is found
(either in the descriptor or in an annotation). That's pretty easy to
avoid if you aren't using Java EE components (such as Spring beans or
Seam JavaBeans). So we aren't really arguing with the spec. But then
again, I'm fine with the stuff automatically loading (spares us the
XML soup) but we do need to be able to disable it from within the
application (not by modifying JBoss AS). If you are saying that we can
put this XML file in the application, then that is exactly what I am
looking for. Why not jboss-web.xml or jboss-app.xml?
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
4:03 p.m.
Btw, this remains a Seam issue until we can get the Spring example to
work on JBoss AS 5. Any Seam user that uses Spring + JPA + the
@PersistenceContext annotation (via the
PersistenceContextAnnotationPostProcessor) will not be able to deploy
to JBoss AS 5.
-Dan
On Tue, Dec 2, 2008 at 10:01 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> AS 4.x did not have a lot of things. ;-)
Yep, and I am very glad to see them in JBoss AS 5.
>> We are not saying the default is bad, just that we would like to control
>> it for issues listed.
>
> That's how the default work.
> Argue with the spec, not me.
As far as I know, though I'm open to be proved wrong, according to the
spec the persistence units are only loaded when a reference is found
(either in the descriptor or in an annotation). That's pretty easy to
avoid if you aren't using Java EE components (such as Spring beans or
Seam JavaBeans). So we aren't really arguing with the spec. But then
again, I'm fine with the stuff automatically loading (spares us the
XML soup) but we do need to be able to disable it from within the
application (not by modifying JBoss AS). If you are saying that we can
put this XML file in the application, then that is exactly what I am
looking for. Why not jboss-web.xml or jboss-app.xml?
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
4:03 p.m.
On Tue, Dec 2, 2008 at 10:03 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
Btw, this remains a Seam issue until we can get the Spring example
to
work on JBoss AS 5. Any Seam user that uses Spring + JPA + the
@PersistenceContext annotation (via the
PersistenceContextAnnotationPostProcessor) will not be able to deploy
to JBoss AS 5.
...until we can provide them with instructions.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
7:48 p.m.
On Tue, 02 Dec 2008 15:33:37 +0100, Ales Justin <ales.justin(a)gmail.com>
wrote:
> AS 4.x did not do this, so it was never an issue before - hence
looking
> for ways
> to have those apps still be able to deploy without a lot of changes.
AS 4.x did not have a lot of things. ;-)
> We are not saying the default is bad, just that we would like to
> control it for issues listed.
That's how the default work.
Argue with the spec, not me.
This is not about spec - this is about runtimes and tooling to be able to
coexist peacefully
without too much fiddling on both sides.
--
/max
9:02 p.m.
On Tue, Dec 2, 2008 at 11:37 AM, Ales Justin <ales.justin(a)gmail.com> wrote:
> ...until we can provide them with instructions.
Can you push this to JBoss5 forum?
I can bring it up there.
Or/and provide me with example - probably the one mentioned in JIRA?
And I'll add JBoss5 specific info that will make it work - hopefully
transparently. :-)
Yes, transparently is what we are looking for.
Here is what you need to do (I'm being very specific even though I
figure you have Seam checked out from SVN).
svn co http://anonsvn.jboss.org/repos/seam/trunk
ant build
set jboss.home in build.properties to point to an JBoss AS 5 installation
cd examples/spring
ant jbosswar
watch for failed deployment in the log files:
java.lang.IllegalArgumentException: Can't find a persistence unit
named 'null' in
AbstractVFSDeploymentContext@15139323{vfszip:/home/dallen/opt/jboss-as-5.0.0.preGA/server/default/deploy/jboss-seam-spring.war}
at
org.jboss.jpa.resolvers.DefaultPersistenceUnitDependencyResolver.resolvePersistenceUnitSupplier(DefaultPersistenceUnitDependencyResolver.java:141)
at
org.jboss.web.tomcat.service.TomcatInjectionContainer.resolvePersistenceUnitSupplier(TomcatInjectionContainer.java:676)
at
org.jboss.injection.PersistenceUnitHandler.addPUDependency(PersistenceUnitHandler.java:123)
at
org.jboss.injection.PersistenceContextHandler.loadXml(PersistenceContextHandler.java:76)
at
org.jboss.web.tomcat.service.TomcatInjectionContainer.processMetadata(TomcatInjectionContainer.java:544)
...
Cheers,
Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
9:12 p.m.
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193858
On Tue, Dec 2, 2008 at 3:02 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Tue, Dec 2, 2008 at 11:37 AM, Ales Justin
<ales.justin(a)gmail.com> wrote:
>> ...until we can provide them with instructions.
>
> Can you push this to JBoss5 forum?
I can bring it up there.
> Or/and provide me with example - probably the one mentioned in JIRA?
> And I'll add JBoss5 specific info that will make it work - hopefully
> transparently. :-)
Yes, transparently is what we are looking for.
Here is what you need to do (I'm being very specific even though I
figure you have Seam checked out from SVN).
svn co http://anonsvn.jboss.org/repos/seam/trunk
ant build
set jboss.home in build.properties to point to an JBoss AS 5 installation
cd examples/spring
ant jbosswar
watch for failed deployment in the log files:
java.lang.IllegalArgumentException: Can't find a persistence unit
named 'null' in
AbstractVFSDeploymentContext@15139323{vfszip:/home/dallen/opt/jboss-as-5.0.0.preGA/server/default/deploy/jboss-seam-spring.war}
at
org.jboss.jpa.resolvers.DefaultPersistenceUnitDependencyResolver.resolvePersistenceUnitSupplier(DefaultPersistenceUnitDependencyResolver.java:141)
at
org.jboss.web.tomcat.service.TomcatInjectionContainer.resolvePersistenceUnitSupplier(TomcatInjectionContainer.java:676)
at
org.jboss.injection.PersistenceUnitHandler.addPUDependency(PersistenceUnitHandler.java:123)
at
org.jboss.injection.PersistenceContextHandler.loadXml(PersistenceContextHandler.java:76)
at
org.jboss.web.tomcat.service.TomcatInjectionContainer.processMetadata(TomcatInjectionContainer.java:544)
...
Cheers,
Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
5617
days inactive
5618
days old
18 comments
4 participants
participants (4)
-
Ales Justin -
Dan Allen -
Gavin King -
Max Rydahl Andersen